Tee Shurts

Drew has a lot of t-shirts, IIRC. It's time he put them to good use.

since we're talking shop today - Adaptive User Interfaces

A recent fluff post on slashdot got me thinking on the general subject of adaptive user interfaces (think Windows Personalized Menus, except think FAR, far into the future, possibly an alternate future, in which such features don't feel like shitting razors). think "subjunctive". I almost posted a comment over there, but decided I was more likely to get an amusing response here.

So there was this stupid article about how the "OS of the FUTURE (echo: FYOochurrr yoochurr yoochur...)" will hide menu items and filter spam for you (holy crapstacy!). Most commentators correctly noted that the journalist does not understand the function of an Operating System and has possibly not used a computer in 7 years. BUT...

1. Do adaptive interfaces have potential at all? Specifically,
2. Can they be implemented such that you can move from computer to computer without getting culture shocked?
3. How could they be made more task sensitive? so in my video editor app if i switch from a mostly-reviewing context to a mostly-modifying context, the toolsets presented should be different. The eclipse 'perspectives' idea is an ever-so-slight nod in this direction.
4. How can they sufficiently involve the user in the process of adaptation?

This last seems like a major problem with the whole idea of adaptive interfaces in general. with most spam filters, you at least get to see when spam arrives, and spend some time training your filter without risk of losing emails that turn out not to be spam.

is there an analogous set of ideas in adapting menus and UI organization as a whole? something that doesn't intrude on your other activities every time there's going to be a simplifying change to the interface? something that splits the difference between "i tediously reconfigure everything myself" and "buggy heuristics and probability filters reconfigure things for me"? an interface must be predictable in its behavior to be usable (doesn't it?). so a big question:

how can an interface be both adaptable and predictable?

And after tentatively agreeing with the Legion of Beardoes that adaptive interfaces are not the purvue of Operating Systems, is there a place for a system-level service that observes behaviors and systematically abstracts them? This sort of thing would allow some crazy stuff:

1. applications that have no relationship to each other whatsoever (besides host platform) can find unexpected harmonies. For example, I have applications A and B open (one could even be a TTY app). When my behavior pattern in app 'A' shifts to "editing" mode (from earlier example), a similar shift is automatically engendered in app 'B'.
2. the same sort of engine could be used for non-human actors and non user-interfaces (APIs)... couldn't these adaptive principals be applied to system optimization? "the application while being exploited by user X in mode Y never makes these system calls -- therefore, the library in which they are stored will not be linked or will be aggressively paged out if the user is in mode Y". things aren't just simpler... they are faster.

This last point just occurred to me while typing all this junk and has me all worked up into a nerdy lather. Maybe I'll regret it in the morning. It is probably the case that existing caching and paging algorithms are far more efficient than this could ever be. Any takers on that one?

So. What do you guys think? Anyone know of (or have written...) any current apps with super-spiffy adaptive interfaces? Dewey, anything from the Newton come to mind?

Eclipse PDE == Ass

Twice I've tried to use the PDE to generate headless builds for my Eclipse plug-ins, and twice I've given up in disgust. This is frustrating because there is a lot of promise in the PDE environment.

Here's my current hit list for PDE build scripts:

Hard coded paths to the Eclipse plug-in jars.

One of my plug-ins generated a build script with about twenty paths that started like this:

..\..\..\..\..\..\eclipse_3.1\targete\clipse\plugins

Holy crap! That is a big pain. I can't run that build from a different branch on my machine, much less on the build portal, without regenerating the build script. Eclipse has provided ant tasks for doing just that, but, if you want to use them, you need to use the Eclipse antRunner. This segues nicely with my next gripe.

antRunner! WTF?
To run Eclipse builds headless, you need to use the Eclipse antRunner application. This breaks the Ant interface, plain and simple. Just typing 'ant' should get some sort of reasonable result. Failing that, typing 'ant -p' should provide some usage information*. Instead, you get to type something like this:

%JAVAEXE% -cp %STARTUPJAR% org.eclipse.core.launcher.Main -noupdate -application
org.eclipse.ant.core.antRunner -data %WORKSPACE% -buildfile %BUILDFILE% 

There's another problem. If your building an RCP application with the antRunner, you're required to have the Eclipse IDE installed on every machine that might make that build. One of the benefits of using Ant is that it allows you to create a build script without IDE dependencies.

I suppose I'm just being a tad pedantic. Either way, I still think the right thing for me to do was to write my own scripts.

Rolling your own
Rolling your own build scripts has it's share of pitfalls. You need to manage your dependencies in two places, which you're probably doing already if you're using Eclipse for development and Ant for builds**. The real hassle is keeping your plug-in version numbers synchronized. I set all of the versions to 0.0.0 in the PDE and I set a version property in the build scripts. Then I replace all those 0.0.0's with the version property during the build. The obvious shortcoming with this technique is that all of your features and plugins will have the same version number. I found this to be acceptable, if not ideal. Your mileage may vary.

Improving the PDE Build Scripts
Three things that could be done to improve headless PDE builds:

1. Store the path to plugins as a property. Then at least the paths could be replaced on the command line. This doesn't work very well if plugins are stored in several places. Those people are probably still stuck with custom scripts.
   
2. Don't use Ant tasks that can only be run from within Eclipse. Also, taskdef, if you don't mind...
3. Support generating a MANIFEST.MF from a build script for use in the IDE.
   

*That is why you use the description attribute on your main Ant targets.
** Maven has a pretty elegant solution for this; use the build to generate .projects files.

Rod and Todd Flanders Nightware

Proper grammar

Drew has taken me to task for taking him to task about the subjunctive (or what I perhaps erroneously called the "hypothetical conditional").

I mentioned that there are a lot of songs out there with misuage, but only one I know of that confronts the issue.

I Wish I Was A Lesbian by Loudon Wainwright III

Which apparently nerds love to make videos with.

Drew also says a little of that song goes a long way... which means this post should go insanely far.

WEEN + Star Wars = me happy

Can't wait for this one

David Johansen

Since when did YouTube's "about this video" section become such a rich source of biographical information?

Blogged with Flock

get your drink on

Things a Man Should Know About Drinking
from Esquire magazine.

I read these once in a barber shop while waiting for a haircut. When I had hair over the winter.

Blogged with Flock

This chicken is screwed.

via:Tyranno.saur.us

Blogged with Flock

Goofus & Gallant Guide to law School

this input device is squirming with disgusting bacteria

the video is cool, though.

Now That's How You Fuck With People

It does, however, require that your neighbors be a-holes of at least moderate intelligence.