Media Technology

From OpenDarwin (thanks to Dave for the link):

I would like to introduce a new addition to the WebKit open source tools—a JavaScript debugger. Drosera, named after the largest genera of bug eating plants, lets you attach and debug JavaScript for any WebKit application—not just Safari.

One of the unique things about Drosera, like the Web Inspector, is that over 90% of it is written in HTML and JavaScript. This is a true testament of what you can do with web technologies today and the rapid development that WebKit allows.

There’s a nice video demo up of the BumpTop 3D Desktop from the University of Toronto’s Dynamic Graphics Lab. Here’s the abstract from their paper (presented at CHI this year):

We explore making virtual desktops behave in a more physically realistic manner by adding physics simulation and using piling instead of filing as the fundamental organizational structure. Objects can be casually dragged and tossed around, influenced by physical characteristics such as friction and mass, much like we would manipulate lightweight objects in the real world. We present a prototype, called BumpTop, that coherently integrates a variety of interaction and visualization techniques optimized for pen input we have developed to support this new style of desktop organization.

I don’t know about this being a full desktop replacement, but for some kinds of applications I could see it working quite well. For example, I’d love it for sorting through tens to hundreds of images or other visual media, especially if they added two-handed or multi-handed interaction to it.

Check out the Bush Speech Generator: now you get to be the guy controlling the radio teleprompter hidden under Bush’s coat! (By way of GeneratorBlog, by way of Dorothy.)

If I were to write a kind of How To Succeed In Business Without Really Trying kind of guide to giving demos of your research, it would probably include the following list of things to avoid:

1. Infrastructure: the only time people notice the plumbing is when it doesn’t work, and the challenges involved are subtle and non-obvious. Stick with pretty interfaces that demo themselves.
2. Multiple caches: Cached information can mask what’s really going on in a system and change the results from one demo to the next. This is even worse when some of those caches involve software that isn’t yours.
3. Multiple threads: Multi-threaded applications are a bear to debug, and are a great way to introduce race conditions and deadlocks that invariably only pop up when you’re giving a demo to someone important.
4. Anything involving networking: Networks are complex and cantankerous creatures that can fail for a number of reasons beyond your control.
5. Wireless: That goes double for wireless. Especially since wireless acts differently when you’re in a room full of audience members who all have their own laptops out and broadcasting.
6. Asynchronous communications: Throw in multiple machines (read: multiple potential failure points) where the same exact user action might produce different effects depending on the timing of how messages are sent and you’ve got a situation where you can successfully test the same demo 10 times in a row and still not know for sure if it’ll work on the 11th try.

Never one to take the easy route, my current research project contains every one of these features. No matter how many successful trials I run, I never really know whether this time it’ll go boom.

Here’s a nice example and how-to on drag & drop sortable lists in Javascript (by way of Steve)

Apparently there’s another Bradley J. Rhodes out there that publishes in a vaguely related field (Cognitive and Neural Systems) and who got his Ph.D. from Boston University at the same time I got mine from MIT. This should cause no end of fun-filled confusion for years to come!

At the Ambidexterous Magazine launch party last night, Chris Tacklind (of D2M, I think) was showing off his laser-diode glove. These things are lots of fun — I remember my group-mate Michael P. Johnson built one when I was at the Media Lab, and got good enough he could make little figure-8s with two fingers while the other dots circled around them.

Something I hadn’t seen before and liked even better was a sound-display toy Chris was playing with, but I forgot to take a picture that one (eit!). It was just a small cardboard tube with a balloon stretched across one end, and a laser diode shining onto a small mirror stuck to the end of the balloon. You’d speak or sing into the tube and the sound vibrations would show up as little laser shows on the wall in front of you. Use it as a drum and you’d get even cooler effects. (Chris goes around teaching kids to make these things — the one he had was made by a 10-year old.)

Now I want to install something like that into the bottom of the little dumbek drum I have. Stretch a membrane across the bottom of the drum and attach a laser pointer to the inside of the drum shining onto a mirror on the membrane such that it reflects up onto the underside of the white translucent drumhead. Aligned correctly, I bet I could get some fun lasershow-style patterns on the drum head on every beat. (Might need to modify the design if the membrane changes the sound too much — we’ll see.)

Remember my continuing rant about how it’s time to just cache the entire Web and keep it local? A start-up named Webaroo has a similar idea. They’re offering free software (Windows only) that caches “webpacks” of pages that make up certain interest areas, and update those caches whenever you re-synch. Their current plan is the usual “pay for it all through advertising” model.

I’ve not tried it yet and don’t know how easy it is to personalize webpacks or how well they handle things like accessing pages that require sign-in, but it definitely looks like a good start. (And if they do the job well, I could easily see them winding up being purchased by one of the big players in search.)

(Thanks to Aileen for the link!)

It took them longer than I expected, but it looks like Google has finally come out with a Related Links feature that people can add automatically-updated links to related searches, news or web pages on to their sites. Think Google Adwords only with search results instead of pay-for-placement advertisements. The text-box is simple to add to any webpage (it took me all of 30 seconds) and gets updated to whatever info is current when the page is viewed — essentially adding dynamic related content even if your page remains static.

I’m pleased to see this concept finally becoming mainstream, especially since the Margin Notes system I developed back in 1999 was a pioneer in the area. One issue that was tricky to figure out is what scope to use as the automatic search term. You can see the problem if you’re viewing this post in an aggregator like LiveJournal or even on my own main page — the search results are probably related at least in part to other posts on the page and not just this one. It’s a hard problem in the general case, but they should be able to get it to work most of the time. (I’ve not yet looked at their code to see what they’re actually doing — more after I check it out.) [Update 12:45pm: actually, LiveJournal strips out all Javascript so it won’t show up anyway… click here to see the actual post if you’re in LJ and have no clue what I’m talking about.]

One thing I didn’t have to worry about with Margin Notes was how to keep the system from being gamed by spammers and Google-juice stealers, though I did have to worry about relevance to individual readers. Something I’d like to see is a similar system that uses my own RSS subscriptions as the core source of info, plus perhaps one level of linkage out (e.g. take my blog-roll & RSS subscriptions plus the blog-roll and RSS subscriptions associated with each of those sites). That would give me some amount of personalization as well as make it harder to game the system.

(via Google Blogoscoped)

Update 12:30pm: I took a quick peek at the JavaScript, and as you probably could guess all it does is send a specially formatted request to http://www.googlesyndication.com/relcontent/content?… that includes the page’s URL. Sure enough, one second after I loaded the page in my browser I saw another retrieval from Google. Makes sense — you don’t want to have to deal with parsing the source document in the JavaScript itself — though it does mean the feature probably won’t work at all on pages that are behind a firewall. (That’s probably all for the best, as otherwise it’d be all too easy to slip up and start broadcasting supposedly-secure information out to Google.)

That said, I’m surprised at how lousy the results are. It looks like they’re relying on their cached copy when available, which for a blog post is, of course, almost guaranteed to not be related to the current post. As for the post-specific page, I’m getting lots of related links about blogs in general, which makes me suspect they’re doing a bad job of distinguishing actual page content from my page’s window dressing, Javascript and navigation bars. That really surprises me (if in fact it’s where the trouble lies) since that’s a problem they clearly know how to solve for their normal indexing.

Dang, I’m late to the party as usual. In case you haven’t seen it yet, as cures for information overload go this looks like it has potential…

(Thanks to Jim for the link.)