November 2003 archives from

Piotr's R&D blog

As a follow-up to my JavaScript Revelations mini-talk, here's a list of some resources to dig deeper into the subject:

• A good, coherent set of short articles on Douglas Crockford's site.
• Doc JavaScript has lots of fairly in-depth articles about advanced JavaScript stuff, including a series about JScript .NET.
• jsIndex is a good gateway to more resources on O-O JavaScript.
• In the talk, I also referred to the future: JavaScript 2.0, Spice (combining JavaScript and CSS?) and JScript .NET (lots more info out there).

I'm still looking for more (coherent) information about Microsoft's HTML components (previously known as Behaviors).

By coincidence, I found out yesterday that JavaScript is a real language! It has a prototype-based object system, full closures, and access to some of the most powerful APIs around—HTML and SVG DOMs, anyone? In many ways, it feels like the spiritual successor to Self. If you're a programmer, go read Douglas Crockford's series of articles right now; he explains how and why JavaScript is misunderstood, and in a comfortable 15-minute read introduces all the critical features of the language. (If you're not a programmer, there's about half a million "JavaScript for Dummies" books out there, but they only contribute to the problem by obscuring the real power of the language.)

Now I need to dig deeper and figure out how to best take advantage of this widely-deployed platform (more installs than Java!). It looks like it might be a good fit for capability-based security (it looks awfully close to E), and with SVG it could be a great platform for UI experiments. Of course, the next major revision may well mess it up, and I need to see what atrocities Microsoft perpetrated in transforming it into JScript...

A staple of modern GUIs is the "default button": within some context (e.g. a window or a web page), one control is singled out to be activated if the user hits the Enter key. This is normally a useful shortcut, and with a good tabbing arrangement between fields can let users get through moderately complex forms without resorting to the mouse. It is especially useful for small one-field forms on the web (e.g. search forms), where you want to type in a bit of text and use it as input for some command right away.

However, the technique can also be troublesome. If there are any multi-line text boxes in the form, it's never entirely clear to me if it's "safe" to hit Enter, or if doing so will submit the form. Worse, it's all too easy to hit Enter by accident, before you're done filling out the form, especially since some (admittedly rare) applications get you used to hitting Enter just to confirm each entry into a field. Herewith a simple suggestion: Enter should only activate the default button if said button is currently visible to the user. No?

At today's Chisel meeting, Karen Parker presented her work on extending users' reach on large tabletops. Her approach is to use a pen to point at items far away and "tractor beam" them closer. She uses a (very expensive) Polhemus pen that senses location and orientation in three dimensions, thus allowing her to compute the matching point on the tabletop. Another approach would be to use a laser pointer with an image-recognition system.

However, our DT tabletops have no cameras mounted above them, and we can't afford a Polhemus setup. We could do the "go-go-gadget-arm" trick, where the user's reach is extended by a special gesture, but I'm not convinced this would be intuitive or easy to control. Instead, I propose the "tablecloth" method: let the user grab the surface and "bunch it up" to bring far away items closer. The distortion should be localized to minimize annoyance to collaborators, and should snap back when the object is grabbed and the auxiliary hand released. This would be easy (easier, at least) to implement if the surface was a deformable mesh, like I suggested in Spacewarps.

Makes me want to revisit the Video Bench again...

At Peggy's suggestion, I exhibited the Video Bench at the UIST reception hosted by NewMIC. It went over well, especially considering that the audience consisted of experts in user interface technologies and that there were 38 other competing exhibits on the floor. I don't have any pictures, but here's the list of ideas from the visitors:

• IBM has a toolkit that does scene boundary detection. I checked alphaWorks, and apparently CueVideo has been retired, but the MPEG-7 Annotation Tool has similar capabilities. We'll have to integrate it into Video Bench.
• Though the DT surfaces are getting larger, they're still not big enough. It would be nice to be able to put together many tables into a larger mosaic, and use it as one virtual surface, kind of like extended desktop in multi-monitor mode on Windows XP. This would be easier to do if all tabletops were connected to one machine, but it would be interesting to apply Brian's distributed variation to this problem.
• There were the usual complaints about the lack of transitions and special effects in Video Bench. One person suggested that fades could be done by cutting a cel at an angle; I guess the fade would either be of fixed duration, or perhaps depend on the angle of the cut. This would take care of 90% of useful transition effects, and integrates well with existing gestures.
• Somebody else noted that there is little context when scrubbing through video, so for example it's difficult to pick a specific frame on which to cut. I think we might be able to fix this by enabling a special spread mode where you spread out one cel into three: the central cel contains only one frame, and the ones on either side show the immediately adjacent frames. When scrubbing through a one-frame cel, special semantics apply that shift frames from adjacent cels through the central one.
• The usual problem of mistaken splices (usually into the non-undoable trashcan) cropped up. The problem is, of course, that the user's focus is where he grabbed the strip, which is often nowhere near the two ends whose location causes actions to be taken. Highlighting to indicate that an action will occur is not sufficient. The movement gesture must be revisited. Perhaps if we get rid of jogging (another dismal failure), we can use single-finger dragging instead? Then you must drag at a divider to make it active, otherwise the strip won't interact with anything.

I also got to see a preview of some other DT work, but sadly didn't have time to roam the reception floor to see all the other cool exhibits. Shame.