Calling All Cryptographers

Been reading a bit about the installation of Kryptos at the CIA headquarters building in Langley, Virginia. The artist apparently spent months working with a CIA cryptographer to devise the codes used for the sculpture. As of today, a subset of the text has been deciphered. Three of Kryptos' four parts have been solved, all in less than fifteen years. (On a related note, if you haven't come across In Code by Sarah Flannery, it's a very good read).

Can it really be that hard to devise an unbreakable, or nearly unbreakable code? Let's try it and see...

Below is a quote, encoded with what I believe to be a trivially simple approach. I challenge anyone to decipher the text. Five hundred dollars goes to whomever can recite the original quote and who can reveal how they discovered the solution. Have fun...

lcsmtkhyfohgvidqgoa
elcgnwemicvtjfrpwq

Hidden Doors

As a child I lived with my grand parents for a few years. Their home was built in the late 40s. My friends and I would explore every inch of the old house looking for secrets. We didn't know where but, according to the movies, there should be a loose stone in the basement, or a sliding panel leading off into some dark corridor between the walls. We never actually found anything quite that dramatic other than some scantilly clad ladies from Zimbabwe in an antique National Geographic or two.

It's quite ironic because though we were simply imagining, Longmeadow, Mass, where my grand parents have their home, happened to have been a major hub for the underground railroad in the slavery era. So many homes built in the town during the 17th and 18th centuries (and are still standing today) have safe rooms, hidden doors, and other such mysterious architectural features.

While Wendy is away on vacation in North Carolina I've been catching up on my horror movies (since they just aren't her thing). I watched Saw II (lots of hidden doors), House of 1000 Corpses (just plain freaky), and a few others I'd been meaning to scare myself with. Got to thinking about a recent find I'd made about my own home.

We recently had our home reassessed by our county, for far more than I can believe is legitimate, so in order to appeal, I had to track down my original blueprints from my builder. To my surprise the plans showed a large (roughly 5'x3') closet in our master bedroom, which, in our instance, is simply walled over.


Above is our second floor plan, showing the closet adjacent to a walk in closet. I can see why they didn't finish it off, not very practical given the bowling alley of a closet right nextdoor. After seeing this I went upstairs, measured a bit, and tapped on the wall a few times. Sure enough, there was clearly a room behind the wall.

I climbed up into my garage ceiling (16ft off the floor via a panel in the garage ceiling), walked over behind where the closet would be, and brushed way the insulation. Viola, a cozy little room sitting unused and inaccessible.

So since I'm still a kid at heart, been looking into throwing together a bookcase to serve as a hidden door. Seems there are a few companies out there who specialize in plans for such a thing.

  
Turns out my next door neighbor actually installed one of these so that he can work from home and his kids won't know he's actually around. He's also a rocket scientist so who knows what other stealth project he has going on (Focker).

I guess there are some legitimate and practical reasons to install. I certainly would be wasting less space - and I'd have an easier means of getting into our garage attic for storage. And then of course, there's always the fact that it's a great hiding place in case of home invaders... or occupying forces...or a place to stash all my gold bullions...

Just suppose.

Follow up: The day after this was posted, boingboing.net had a small story about Creative Home Engineering, a design firm that'll hook you up with *the* coolest home kinematics: paintings that reveal thumb scanners, hidden rooms with candlestick entry, etc. Check out the animations in the video section.

We Make $hitty Software - Encore

Came across this oldie but goodie on Dave Winer's site, - a posting from over ten years ago. How little things really change.

An old software slogan at Living Videotext: "We Make Shitty Software... With Bugs!" It makes me laugh! We never ran this slogan in an ad. People wouldn't understand. But it's the truth. We make shitty software. And so do you!

Software is a process, it's never finished, it's always evolving. That's its nature. We know our software sucks. But it's shipping! Next time we'll do better, but even then it will be shitty. The only software that's perfect is one you're dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it's a process. We'll make it less shitty. Just watch!

Talking with an unhappy customer, first validate their belief that you've let them down. I agree that our software isn't perfect. You won't get an argument here. Let's move on, find a workaround, a way to get your data back. And we promise to take a look at this problem and, if possible, fix it in the next release.

So, when you get an upgrade, you look for the process, see if they responded to your needs. Which way are they moving?

Boxely - The Other Woman

Sree Kotay, my department SVP, spun a great yarn (a bit fatter than a thread heh) about our interface technology, Boxely. As most people know (especially my wonderful wife Wendy), I've lived and breathed the project for over a year and a half now - and my wife considers her (Boxely) to be the "other" love of my life. So I'll try to remain as impartial as I can.

To provide a bit more history, Boxely has certainly come along way from the initial exploratory prototype Joe Hewitt poured himself into a couple years back. Sree did not mention XUL to a great degree in his post, but without going into too much detail (Joe does), we did not set out to build your grandma's UI toolkit.

All of the core team members came from different backgrounds, but we'd all felt the pain of building hi-gloss, highly dynamic UIs, without there being a tool to make it easier. Joe initially set out to evolve XUL. I came from the Macromedia Flash world, and longed for the power of Flash in a desktop UI language - with the performance of a desktop app. A toolkit with the high-octane dynamic nature of Flash that was integrated with the OS (native clipboard, drag and drop, shell support). All of our original thinking was pre-XAML but was inspired by what XAML promised for the future - we just couldn't wait.

What Sree calls self construction, I call element composition. One of the most compelling aspects of Flash to me (later generations) is the ability to composite movie clips (within movie clips, within movie clips) to construct just about anything one can imagine. Combined with a styling engine and code-behind Boxely is Lego-Mindstorms for UI development.

As for other aspects of Boxely worth note - animation w/interpolation as a primitive (whether you like the syntax or not), is a huge plus. And (thanks to Platform Basics), raster based transitions, layout transitions, imaging effects, affine transformations, and procedural UI are the heart of Boxely. (Much more to evolve too though, more on that in another post).

I have to disagree with Sree a bit about CSS. I despised CSS as well, though primarily only for its syntax - which Boxely solves by defining a more intuitive and consistent (XML) language for styling gadgets based on their property "state". Boxely does not support CSS in the W3C sense. It does support "cascading styles" that allow one to "style" the visual properties of an element, or an element's sub-component (part), or a class of elements - essentially providing for the same types of selectors that CSS does in the HTML world. Cascading styles is invaluable and core to the power of Boxely's themability and flexibility of visual style. I would guess there are a ton of CSS zealots out there who might disagree with Sree's take on the value of cascading styles.

As to the implementation of said style language and its complexity - I would separate the language from the implementation. I am convinced that the implementation does not have to be quite as complex (forests of graphs, the busy-ness of recascading). We have made huge dents in the efficiencies of the underlying styling engine since its inception - and I agree we have room to improve.

Briefly, on why not to style attributes - (trying not to start a flame war with my SVP, heh) - it is pretty simple IMHO. Style rules, and the triggers that dictate what visual styles are applied when - is 100% based on the state of an element. Specifically the style rules are fully attribute and property driven (e.g when hovered == true for this element apply a procedural color transform). The current complexity of cascading style engines is all due to the need for resolving ambiguity and precedence given the layering of selectors. Not to say its impossible but if we were to allow cascades to also style attributes, which could in turn trigger other cascades and other style rules, which could in turn trigger additional cascades - you will have bigger problems than just ambiguity - you will have much more complex chain reactions occuring which would not be conducive to a performant application.

As for the JavaScript language binding and some of the memory related issues we've run into because of this - that to me is also quite separate from Boxely as a UI language. As Sree knows the original code-behind languages of choice (as implemented) were Python and C++. I believe the factors behind moving to Javascript were valid - and the approachability by classic multimedia developers to the toolkit was a huge benefit internally. As with life too much of anything sugary sweet is bad for you. And by tweaking our best practices internally (how to properly use Javascript efficiently, when to promote procedural code to native code, etc.) its certainly not an unsolvable problem.

Not sure what Sree means entirely by his aversion to flex and flow. Boxely, along with most other next-gen declarative UI languages, provides plug and play layout models on a per element basis. While flex and flow are the most common - vertical flow, stack, grid, and absolute positioning of elements are available stock as well. If Sree again meant the core implementation - not the language - I concur. We already smoke MXML, XAML, and even XUL in many layout related tests, etc. we have many more no-brainer speed improvements we could make.

Per Sree's note, we'd love to release our little toy (Boxely) to the general UI geek community to play with. Maybe when we're complete with the current round of lypo and post 1.0 tweaks? I want to stress - our little team is not out to "save the world" by any means - Boxely currently is simply just an enabling technology for us here at AOL - but in alot of ways it's what DHTML should really be - or what XUL 2.0 should really be. At a minimum if we inspire enough folks to finally push ourselves away from HTML as the primitive layer of distributed UI - I'll be a happy camper.

PS. One unfortunate side affect of the next-gen UI layers is that they well, are *never* as performant as raw win32 apps. XAML (WPF), XUL, MXML, even .NET forms - are always one step behind your to the metal GetDC()/Blit() Win32 app. No reason in particular it has to be that way forever, given hard work. We're at the crux of the new generation of hollywood UI. It's only a matter of time before the technologies are fine tuned.

Sponsored Commute

I have become increasingly frustrated with the prevalence of ads in my daily life. Over time I've grown to accept ads in traditional media (television, newspapers, and magazines primarily) but it seems like in the past two to three years every inch of cyberspace and truespace is fair game for a billboard. Corporations bleed billions of dollars to make a name for themselves by annoying us and burning their imagery into our retinas.

Take a stroll through any major city and look down - you're bound to see bumper stickers and logos glued to the sidewalk; to your left and right corporate sponsored graffiti tempts you to "get in the game!". You look up in desperation only to see giant banners painted onto the skyscrapers and 100ft sq. televisions beaming a catchy jingle into your cortex. You cell phone chimes the T-Mobile ditty to grab your attention only to remind you, "You've Got Spam". After finding the nearest Hot-Spot to get online you fire up your trusty instant messenger program and BAM! - a life-sized replica of Shaq jumps out of your buddy list onto your desktop to pitch "7-UP-Yours!".


I'm the little guy... I'm using all of these products because I like them, I really like them. Why do we have to suffer through the din and ballyhoo of these companies while their executives get wealthier and wealthier by the “click”.

Just suppose we all start getting in on the game. Why not? Hell, I commute 100 miles each day, I can't tell you how many houses I pass with my little 2001 Honda Accord beater. I drive kinda fast too, so I pass a ton of commuters. Gets a little congested around the toll booths, gotta be a great opportunity to sell, sell, sell!

Hook me up Crate and Barrel! Gimme a little of the action GoldenPalace.com, AOL, Yahoo!, Google (oh Google, you sly dog you, tattooing my emails and my search results with ads all day every day). Tattoo this! I'm your new billboard baby!

This post was sponsored by Feed the Developer, a not for profit organization.

Just suppose...

Live Lists

In 1993 I wrote a program called K-Base for DOS using the great little database engine Clipper. K-Base had a very simple interface, ala Windows Notepad, with which a user could jot down anything they wanted to "remember" free form and file it away within their own personal knowledge base. Each new knowledge entry could be tagged by category and/or keyword and later retrieved via plain text search, or filtered by tag. A user's personal knowledge was by default private, but the database itself was distributed such that articles could be marked as searchable by all or by only select users.

It was amazing to see how such a very sparse interface glued to a database backend could result in an organically "grown" collection of random knowledge. Essentially an extension of the brain. This was before the days of wide PIM usage, before full featured mail clients with built-in indexing, before today's MS Office productivity suite, before even Google. Each individual it turned out, made use of the knowledge base in different ways. Some would jot down to-do items or day to day project notes, others would keep track of contact/customer information, some would use the system as a work log. Since select articles or entries could be marked public, people could sort and filter the archive of shared knowledge by simple manipulation of tags depending on their need. For example, I can't recall Jane's phone number but I know she's a close friend of Jim's, lemme filter Jim's public knowledge by "Jane" and "Contacts".

The motivation for such a freeform system was simple - I don't have time to figure out what application to start up to help me "remember" what's on my mind...why do I have to keep my notes in text files spread all over my hard drive, my addresses in an address book application, my "Too Due" lists on sticky notes all over my desk, my wish lists in the back of my mind. Why can't I just type away into a common interface and say "remember"...the application with minimal guidance will organize and relate my knowledge in a logical and meaningful way, and allow me to quickly recall what I need to and when I need to.

Using the system was extremely liberating, especially as I began to trust the system to safe guard what was on my mind. Meaning when I had a thought, or wanted to remember something important, I would simply offload the knowledge to the database. The database engine would take care of sorting, collating, filing, and relating the information for me.

A lot of what the tool was used for in our close group of co-workers was to keep track of and manage lists. Lists seem to be the see-all end-all of information organization for us in the current age. Everyone has a to-do list, and a contact list. There are must-see lists, "favorites" lists (web sites, movies, songs, artists, books, foods), grocery lists, best friends, birthdays, appointments... our lives it seems are sometimes driven by lists. Lists are a very valuable tool for organizing the mind.

I've been thinking a bunch lately about what a modern knowledge base application would look like, feel like, and how it would help me in my day to day -- with features relevant to modern day computing (the ability to associate video, sounds, images with an entry; a means to access ones personal knowledge base remotely via the web, or via instant messaging; and integration with other's knowledge in a seamless manner).

One concept I would love to see in such a next-gen KBase would be "live" lists. Lists that I can append to and manage as quickly as I can type, but that would then passively become even more valuable than the list I originally constructed. For example. Each week, my wife and I maintain a grocery list, unsorted, unorganized, and free form on a scratch pad on our refrigerator. On Saturday off we go to Food Lion, splitting the list down the middle and bouncing around the store looking for each item. I would love to be able to just start typing a grocery list and as I add each new entry, the list would automatically be sorted and grouped by category of grocery item. If I were to type "toothpaste", "eggs", "milk", my live list automatically morphs into:

DAIRY

• Milk
• Eggs

TOILETRIES

• Toothpaste

Even better, let me add a few items while I'm at work via an instant messaging bot, or view the final list sorted and collated at the end of the week by the aisles in my local grocery store.

Another list I keep in my head, which I would love to share - is my favorite movies list. I want to just, from recall, sit down and type in all the movies that have moved me in some way. As I type I want the "live" list to go out and retrieve the movie posters for each movie, or the imdb rating, or local movie times for movies that are still playing, and have my list come to life before me. With a push of a button it should be just as easy and "auto-magic" to share my list of favorite flicks with those visiting my website, blog, or "space". My knowledge in essence should be "threadable" and shareable with the world.

More on some next-gen KBase thoughts, and maybe a live list prototype or two coming soon.

Just suppose...