Magic Ink

You're answering your own question : it's hard to get out of the default elements available to us (checkbox, textbox, etc). They're so fast and easy to use that we don't think about better solutions.

But there's something else not mentionned in the article. It's the lack of "innovative users". When people are confronted to a new interface without checkboxes and textboxes, they are afraid and they don't know what to do. We are to blame for that situation because we overuse these elements in all of our applications.

I think the reason we're still putting combo boxes and radio buttons on things we call "forms" is a chicken and egg problem. We have the form building tools, so we use the form building tools. Because we're using them, people make them. And the trend continues.

I have a project coming up at my university where I will be designing a simple online game creation utility. I've been thinking long and hard about what kinds of interfaces this would require. All I know so far is I will not make it 'wizard' or 'form' based.

It's a lot harder than it looks, actually.

Visual design is more art than science still, and even when it can be made fairly rigorous finding people who not only can make a good design but also articulate its logic in a formalizable way is well-nigh impossible; they're out there, but it's a really rare skillset.

What you'd encounter if you started going down the route of implementing something like that in magic ink is that it's easy to make mockups in photoshop, where you have control over design and content-to-display; once you get into the real world you have a world of edge cases to deal with.

On an individual level these are often easy to solve, once you're aware of their existence, but the richer the visual display the more overwhelming the edge cases come in.

Here's a trivial example from that widget: along the left edge you have columns of "fare types" (internet special, refundable, etc.) that have the respective price quotes at the same horizontal level as the itinerary; after the lower left corner they wrap down-and-to-the-right and have definitions of the fare types.

For a single purpose -- airfare -- with a static set of flight types this display system could be made to work, but here's some things to consider:

- you notice how the # of flight types is exactly the right amount to match the height of the price quote section in the lower right corner? how pretty would this layout look if it was a few types too short or too long? There's stuff you could do -- adjust relative font sizes, etc. -- but doing that in an automatic fashion is tricky and invites more edge cases to emerge, and what's worse it might screw with the visual hierarchy (b/c human visual perception of relative font sizes isn't all that precise)

- you notice how the definitions of flight types are all short enough to fit in the available space? what visual idiom ought to be used if there's too much text (there's lots you could opt to do, but you have to pick something and make it work)?

- what is the visual idiom when the # of flights available on that day is just ridiculous (like the east coast "shuttles" which fly on the hour, every hour)? unless you have a giant screen you're going to have to scroll in some fashion, but what kind of scrolling (only the flight panels, the entire screen, etc.?)

These "problems" aren't so much hard algorithmic problems as just decisions that have to be made, and then stuff that has to be made to work.

For limited use -- where most of the requirements and, more importantly, most of the extreme ranges -- are known in advance, it's possible to craft something like this, but to make a general, reusable component for something like this is far harder than it seems at first.

Automating aesthetics will happen at some point, but it's tricky.

I remember finding this article on Digg in April '07. To me it was gospel - I contacted the author thinking for sure someone else had shared his vision and wanted to bring these ideas to all kinds of applications. At the time, not really - he had gotten a lot of attention for being innovative, but in terms of deeper interest it was mostly from those academically interested in the ideas. (although perhaps Apple hired him for their deep interest as well).

Why did this fantastic article take so long to make its way to hacker news? In fact, I ask myself why I did not submit it here having read it half a dozen times over the last couple years.

I'm not sure I can answer this question. But to me there is most definitely a delay between the output of innovative, unproven ideas, and the acceptance of even discussing these ideas in an engineering community. Maybe somewhere in this dynamic lies the answer to both our questions.

Only doing what I'm told :)

There's a PDF link at the very top of the page. Is it more readable for you that way?

I find your comment rather astute. I have great eyesight and a high resolution monitor, but these diagrams are too busy to really be practical on a conventional PC monitor at this time.

The Amazon mockup is a great example. It uses 50% more screen real estate and nearly illegibly small fonts. I can hack it on my 1600x1200 monitor but that would be hell on a PC running at 1024x768 with low color depth (or no anti-aliasing) and a bunch of spyware/toolbars installed.

Amazon also uses the data from people clicking links and browsing to analyze customer preferences. You can't do that with all of the data on one screen.