Blog posts tagged "design"

PrinceXML: XSLT Alternative?

December 5th, 2005

I’ve had a todo item “Check out PrinceXML” since seeing it mentioned in ALA’s Printing a Book with CSS.

So I got so far as figuring out it wasn’t opensource, and seeing that the price was $349 dollars. Definitely makes me think I should probably shuffle that “Learn XSL” up the todo list again.

Still I’m very intrigued, and will probably download the trial version when I’ve got enough free time that I can pour some into learning a proprietary tool.

Anyone else played with it?

Tagged: Uncategorized , , ,

Brand and Culture: Jasmine got a blog!

October 26th, 2005

So much happened in the last 3 weeks while you’ve been deprived of my piercing insights, its hard to know where to begin catching up.

To me the most exciting news is that Jasmine now has a blog, brandxculture (pronounced ‘brand and culture’). Truth be told she has had it for a while, but only recently officially launched it.

My favorite posts so far are

Tagged: Uncategorized , , , , , , ,

Atom 1.0: Why Oh Why?

August 16th, 2005

Spent a little time with the Atom 1.0 spec last night on the plane, and I’m coming to the conclusion that it was invented for the sole purpose of making my life difficult. (or perhaps less ego-centrically, making writing feed parsers more challenging)

I don’t really have the expertise of having actually upgraded a parser to add support for this entirely new, utterly backwards incompatible to a degree that makes the so called 7 incompatible versions of RSS look like a fond memory, but a handful of issues that are going to make my life unpleasant jumped out at me. (Maybe I’ll update this list over time)

Arbitrary Renaming

Is “published” really that much better then “issued”? Sure its a small change, but there are literally dozens of seemingly arbitrary word smithing, that makes maintain both a Atom 0.3 and Atom 1.0 parsers in parallel annoyingly cluttered.

updated (nee modified) now under defined

In Atom 0.3 the “modified” element was strongly defined, in that it was required to updated with each edit. This is no longer true. And while we’ve all spent the last 5 years developing expertise trying to guess whether an element has been updated with weird hashing/diffing techniques, it would have been nice to start forgetting about such stuff.

I Miss version

Sure a namespace is “proper” way to do things, but I miss the pragmatism of the version attribute. (what little pragmatism survived to find its way into Atom 0.3 seems to have been beaten out of Atom 1.0)

dc:subject

Dublin Core is a noble piece of work. At its heart it is trying to formally define some basic building blocks which can be universal truths in a digital age. Its like running code version of Semantic Web. So why is the use of dc:subject deprecated in favor of an overly complicated “category” element which, while being similar to the RSS 2.0 category element, has a different for the sake of being different feel to it.

The Atom “category” element

<category term='MSFT' />
<category term='MSFT' scheme='http://www.fool.com/cusips' />

vs. RSS 2.0

<category>MSFT</category>
<category domain="http://www.fool.com/cusips">MSFT</category>

Never thought I’d call an RSS 2.0 design decision[ clean and well thought out, but its all relative.

Content by Reference

One of Atom’s innovations is introducing a standard “link” element, allowing it to leverage and become a first class citizen of this Web thing which seems so popular. (I’ve written about this before, and mourned Kevin Burton’s mod_link)

So why does the Atom “content” element now allowing for “content by reference”, with the “src” attribute? Honestly, this seems like a clear case of confusing duplication. TIMTOWTDI is one the key factors people point to when claiming that Perl is an ugly, under designed, confusing mess.

For example, are there now two, valid but disparate ways of encoding podcasts in Atom?

And should a toolkit parsing Atom 1.0 automagically deference the URL defined in “src” attribute? I mean, if I’m parsing a feed I expect to able to display the contents of the content element. And if so, are we back to those wonderful bygone days (cough “rss2:enclosure” ) of baking dangerous required behaviour into our processing model? (speaking of process model, shouldn’t the Atom 1.0 processing model address this?)

Tagged: Uncategorized , , ,

August 12th, 2005

The Head First Girl’s Double Life

Tagged: Uncategorized , , ,

Netflix Sparklines

March 15th, 2005

Like many geeks I secretly covet Tufte’s serenely assured design sense, and fetishize his pronouncements. That said, most sparkline implementations I’ve seen have left me confused. The sparklines that Nat is generating of Netflix rental data are different. They’re great. Great in the sense that they’re small, and trivial, communicate exactly what they’re supposed to do.

Looking at my last 16 months of rental history , you can see that I almost always spend on an average more per movie then I would have at the corner video store ($3/video). Either I’m a sucker, or am I getting some other value out of it. Either way, that itty bitty graph packs an amazing amount of info in.

And he’s got a service setup where you can generate your own.

Tagged: Uncategorized , ,

RSS 1.1

January 19th, 2005

Looks like a couple of folks active in the rss-dev working group have taken Ian’s excellent RSS issues document to create RSS 1.1. This is a great idea, and one a long time coming.

The execution leaves me kind of cold. A list of changes from RSS 1.0 is given, however it’s written in some dialect (maybe high semweb geek?) that I don’t speak, so the disambiguations are ambiguous.
The major changes I can see are:

  • rdf:Seq has been removed in exchange for a more liberal of sprinkling of opaque RDF attributes. I’ve never figured out why rdf:Seq bothers people.
  • channel is now Channel
  • Channel is now the root element. Ick, that doesn’t match my internal modeling of what a channel is. But I’ll admit that is a personal thing.
  • through out the document the use of the rdf:about attribute on items is repeatable discouraged, which is unfortunate as this value acts as the defacto guid on RSS 1.0 feeds. Brent agrees. Already changed, apparently.
  • only allowed charsets are UTF-8, UTF-16, and UTF-32. Umm, I have better tools for dealing Shift_JIS then UTF-32, not to mention the relative dominance of ISO-8859-1

What didn’t change

  • Not addressed one of the single ugliest outstanding issues in all RSS version, Markup In Core Elements. One of Atom’s clear advantages.
  • language is still confusing and inaccessible to non-RDF hackers
  • no standard for providing a unique identifier (like RSS 2.0’s guid and Atom’s id elements), and a distinct discouragement of the RSS 1.0 semi-equivalent.

I’m torn whether these changes are too drastic to justify a single sub-version increment (I’d expect all tools that work with RSS 1.0 to work with RSS 1.1, which won’t be true), or whether they’re too minor to justify adding yet another version of RSS into the already crowded, and confusing space.

I think Sean and Chris are doing good works, a clean up of the RSS 1.0 has been a long time coming. But my (very) quick glance at what they have says they haven’t nailed it here. Good discussion going on on rss-dev.

Tagged: Uncategorized , ,