NOTE: This article is out of date. Efforts may be made in the future to remedy this, but will probably result in a complete rewrite. It is provided here for posterity only.
The biggest part of updating WaterPigs.co.uk to be my fully functional personal publishing domain has been (is) creating the back end and IA.
At the time of writing, I have the following system:
- A DB
- A ‘publish’ form
- A public front end
- One content type: generic ‘blog entry’, stored as markdown with HTML wherever I need it
- The ability to post the article out to Twitter
To make things more interesting, I need to specify different content types. The benefits are obvious:
- Intelligent filtering e.g:
- a podcast feed could be made automatically from all the audio posts
- Instead of having a monolothic chronological list of content posts can be presented in different ways depending on their type
- Syndication can be altered depending on the type of the content
The Inspiration
After seeing Tantek Çelik’s Whistle URL Shortener Design Notes I decided to base my schema off his. Therefore I am using single letters as type designators.
Note that I don’t yet have a URL shortener — this schema is for internal post type classification.
EDIT After reading through the Activity Streams Spec I realised that some of the post types I had dismissed previously (namely: d (change/modification), u (update) and possibly w (wiki)) could actually be extremely useful, but required an extra distinction to be made: ‘posts’ vs ‘activity’.
I’ve updated my schema and I will write up an article on these design decisions once I’ve set them a little further into stone.
Draft Schema
Contains all from Tantek’s Whistle spec, with annotations based on which of these actually mean different things to the others? And more importantly, which will be displayed differently?
NI = Not Implemented; with a subitem starting WAS means it was in the Whistle spec but I won’t be using it.
- a - Audio Recording, speech, sound, music track.
- Valid due to unique meaning and presentation
- Will be used as a filter to generate podcast feed
- b - blog post, article, essay (structured)
- Valid.
- c - NI
- WAS ‘code/sample code’, but presentation (and meaning, to a degree) will be the same as b (e.g. all code samples will have associated narration and document structure)
- d - difference, edit, change
- This is not a post type, but an activity. More on this later.
- e - event (hCalendar)
- Valid as these will be displayed significantly differently to other content
- f - NI
- WAS ‘favourited. Primarily a URL to someone else’s content’.
- Unsure about this one. It does have a different meaning to (for example) r, but how useful would storing them as different be?
- I use services like browser bookmarking and evernote to maintain lists of my favourite content, and they do it very well. Of what extra use would this be, to me or anyone else?
- Probably best to use a t or r for this.
- g - ‘geolocation’ or similar
- In theory this could be useful, especially if I get into location based blogging. Valid as a distinct type (from, say, t or u) due to sufficiently different presentation.
- h - NI
- WAS ‘hyperlink’, permalink, untrustworthy
- Unconvinced of the usefulness of this. * What function would it serve that f u or n wouldn’t? Does it require different presentation?
- i - NI
- WAS Identifier
- Not convinced of the usefulness of this.
- j - NI
- k - NI
- l - NI
- NI due to similarity with 1. Fair enough, works for me.
- m - NI
- WAS ‘message (email-like)’
- I’m unlikely to use this — my blog is for public stuff and this is inherently private.
- For the moment I will continue to prefer email for private communication, but am looking into FSW alternatives.
- n - NI
- o - NI
- WAS ‘physical objects’
- NI due to lack of usefulness. Perhaps when a WOT is a reality it will be useful.
- p - photo
- Sufficiently unique in meaning and presentation
- q - NI
- r - response, reply (short), comment regarding
- WAS ‘review’ as well as the above. I rarely review stuff (would use blog format post to do so anyway, possibly with hReview markup), and response/reply is more useful to me.
- Difference between this and other similarly formatted types (b, t): others are standalone, r is usually much shorter and only makes sense in context
- s - slides, presentation
- Yep, valid as this has significantly unique meaning and would require alternate presentation
- t - plain text, note, tweet
- Yep, valid.
- u - update
- Initially I wasn’t sure about this one. It is useful, but not as a post type — a text note is a post, an update is an activity. More on this in a later post.
- v - video recording
- Again, valid due to differences in meaning and presentation
- w - Possibly NI
- WAS ‘work, work in progress, wiki, draft, task, todo list, gtd’
- I may implement this — certainly I can see that there are tangible differences between a b and a w.
- x - NI
- WAS ‘XMDP Profile’
- Currently debating the usefulness of this with myself, mainly because I don’t fully understand XMDP profiles.
- As I don’t understand them, I am unlikely to implement them.
- May be implemented in the future.
- y - NI
- z - NI
Final Spec
So, the final spec I am using is as follows:
- a - Audio Recording, speech, sound, music track.
- Will be used as a filter to generate podcast feed
- b - blog post, article, essay (structured)
- d - Change/modification
- This is not a post but an activity
- e - event (hCalendar)
- Valid as these will be displayed significantly differently to other content
- g - ‘geolocation’ or similar
- p - photo
- r - response, reply (short), comment regarding
- Difference between this and other similarly formatted types (b, t): others are standalone, r is usually much shorter and only makes sense in context
- s - slides, presentation
- t - plain text, note, tweet
- u - update
- Like d, this is not a post type but an activity type.
- v - video recording
So, that’s significantly pared down and contains only what I consider to be ‘primitives’ as such.
I’ve been purposefully merciless and removed anything I don’t think I’ll use, anything I think is duplicated or best expressed by another format.
I’ve removed things like ‘u’ (update) even when it ‘feels’ different to ‘t’ (plain text, tweet). To me, an update feels like a different thing to a note, but for all purposes of presentation, storage and implementation they’re exactly the same.
As for ‘r’ (reply), I had to think about that one for a while, as a reply could easily be a ‘t’ (short comment) or ‘b’ (full blog post). In the end I decided that ‘r’ was distinct from ‘t’ as ‘t’ should be stand-alone, but ‘r’ is allowed to be taken only in context. Naturally the UI I build will reflect this, containing an excerpt from the target article.
Phew
I think this has been an awkward but important stage in deciding the IA for WaterPigs.co.uk.
I’d encourage anyone who maintains a blog-like personal site to have a think about the different content types they store and how best to organise them.