Think Info

Exploring the information space

Category Archives: Information Architecture

On third-party transclusion

On 25 August 2014, Sorin Pintilie (@sorpeen, published an article on The Pastry Box Project, discussing a mechanism that would allow content to be transcluded into a web page, by applying an href="…" attribute to a <p> tag. This article is a response to that.

Transclusion is the inclusion of a small element of content from one source into other material, by reference. The transcluded content is presented as an integral part of the final material – at the point of reference – while remaining dependent on its primary source. It is included at presentation time. The principle of transclusion was part of the original description of hypertext, as published by Ted Nelson in 1965.

There are two variants to transclusion. The first, as envisaged by Nelson, is the easier: content reuse within a single publishing environment. Sorin’s article, and this one, deal with the second type: including a snippet of someone else’s content into your publishing. Read more of this post


Semantic long-form

Long form: it’s been the basis of communication for millennia. We tell stories; we’ve been successfully sharing concepts with others this way for as long as we’ve been recording history – indeed, long-form communications is perhaps the fundamental enabler of the very concept of history.

Why, then, do we have such trouble migrating this most basic form of communication to the digital realm? What about how we create, manage, maintain and distribute long-form content makes it machine-unreadable?

Personally, I blame Xerox.

Space Diner, by Chris Shipton Read more of this post

What does your CMS actually do?

You’ve shelled out the money – six figures very likely. You have the license. The wonderful CMS they sold you is yours to use. So, what are you going to do?

In other terms

I am no musician. My fingers do not obey my instructions when it comes to evoking the melody. But, I wanted to learn. The piano is supposed to be a fairly basic instrument; maybe not the easiest, but the notes are all laid out in front of one is a fairly obvious way.

I went into a music store and asked a salesman which piano I should buy. I was honest about not having a clue; not knowing how to play. But I have a good ear for sound. I know if I like the tone of something. All smiles, he took me to one special piano he had; I closed my eyes and listened while he played. The piece was hauntingly beautiful – a minute and a half of lively bounce. Chopin, he told me; Étude Op. 10 n. 5. A piece that demonstrated no lack of skill.

Sold. I handed over my money and awaited delivery.

Was I ever in for a shock? A week later, the very piano the salesman had played me that demo piece on arrived and was set up in my living room. I lifted the lid to see what my new toy sounded like in my home – and discovered that half the keys were missing! On the right half of the keyboard, there was only the single white key; an F. Read more of this post

KISS and the black box

I have been told, over and over, to keep the systems I design simple. The mantra is familiar; we all know it well: KISS – keep it simple, stupid.

Everyone and his half-brother is quoted saying something of the sort:

“That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

Steve Jobs

Now, I have a big problem with how many people choose to interpret this concept of simplicity. There are several ways in which KISS can be applied.

KISS and the black box

KISSing the system

This is the aspect of KISS that people like Jobs have referred to: it is about reducing the set of requirements; eliminating second-tier functionality.

KISSing the system is about identifying the tasks that really need to be supported, and eliminating the rest. If you can halve the number of tasks the system supports, thereby halving the overall complexity, while maintaining 90% of the user-task needs (i.e. the retained tasks are used more than the discarded), your return on effort will increase.

Of course, just because a task is not frequently performed does not mean it is not critical (e.g. a purchasing process involves putting items in a cart, and a check-out; just because the average shopper selects five items before checking out does not mean we can do without the less-used step). Read more of this post

Dependency awareness (content’s identity crisis)

Is your content having an identity crisis? Does it know what it is?

Content's identity crisis

When elements of content become individual entities, separate from the environment in which they are presented (which is the whole point of a CMS, but that’s another story), the need for awareness of these dependencies becomes critical to the “management” part of the CMS.

Most vendors will tell you that their systems are aware of content dependencies: if you create a new page, with an image in it, publishing the page will also publish the image. Hey, the page is aware of what its dependencies are; what more could you want? Read more of this post