Archive: April, 2005

Jessica and I are flying to Seattle tomorrow. We’ll spend the weekend with her brother, Jeb, taking in the sights and sounds.

The rest of Jessica’s family are going to meet us there and together, we’re all going to go on a relaxing cruise up to Alaska. Not on one of those big cruise liners, mind. This is going to be a more intimate affair.

I may have to spend half the time in my cabin, hunched over my iBook, doing some unavoidable writing but at least I’ll be getting some Northern exposure.

Speaking of which…

When that show was still running, I used to get mistaken for Ed all the time. Seriously. On a trip to the States, I had three different people tell me, "y’know, you look just like Ed from Northern Exposure".

I wonder if Robert Scoble ever gets mistaken for Philip Seymour Hoffman.

It looks like I’ve been chosen as a guinea pig for a design that Amazon is considering. Changes like these are usually served up on a small subset of Amazon’s servers. It’s then delivered to a correspondingly small subset of visitors.

More gradients. Just what the Web needs.

It looks they’re going for "less is more" with the tabs.

I mentioned a little while back that there seems to be more and more bits of me scattered around the internet. My photos are on Flickr, my wishlist is on Amazon, my links are on Del.icio.us and my events are on Upcoming.

I’ve been working on a way of pulling these pieces together. This is what I’ve come up with: Adactio Elsewhere.

All of those sites I mentioned have something in common. They all provide APIs. I like the idea of using each API to display the different services in a combined way.

I intend to write up the process of building my little app in more detail. I’ll document the back-end and front-end programming and put it in the articles section. For now, let me give you a quick run down.

First of all, the back end…

I’m using RESTful requests to send and receive information from each web service. This isn’t out of any ideological bias against SOAP or XML-RPC, it’s just the simplest and easiest way to get something up and running.

The XML being sent back is parsed using PHP5’s superb new DOM functions. If I was trying to parse XML in PHP4, I’d have to write a function or class (or use one that someone else had written). In PHP5, it’s all built-in.

I’m particularly fond of the Amazon API because it allows you to specify an XSL file to style the returned XML. That said, the Flickr API was probably the nicest to use. It’s very feature-rich and well documented. Both the Del.icio.us and Upcoming APIs are relatively new and will probably be introducing more features and options.

The Flickr section pulls in my contacts, my newest pictures and the newest pictures from my contacts. Clicking on a thumbnail brings up a larger view of that image. Clicking on that brings up a larger view again. Clicking on a contact’s username starts the whole process again but this time you see their contacts, their photos, etc.

I find it quite addictive clicking through to pictures from someone who is a contact of a contact of a contact.

The Amazon section has a link to my wishlist. Clicking on an item in the wishlist brings up the item’s details. There’s also a form so you can search through the shop for anything you want.

The Del.icio.us section shows a list of the latest links. The Upcoming section shows a list of future events. Pretty straightforward.

I also threw in a little RSS reader. I put together an OPML file of RSS feeds from my friends and acquaintances. The feeds are sorted alphabetically. Clicking a letter brings up a list of people whose name starts with that letter. Clicking on a name shows the latest posts from their feed. Clicking on the title of post will show the post in full.

Once I had all the back-end functionality working, I covered it with a nice dollop of Ajax. This is pretty much exactly what I was talking about before: progressive enhancement with Ajax.

First I built the old-school version replete with page refreshes. The Ajax script intercepts the actions that would normally trigger a page refresh and just refreshes the relevant portion of the page instead.

You can view pictures on Flickr, shop at Amazon and read RSS feeds all from the same page without a single page refresh.

I encourage you to switch off JavaScript and browse around Adactio Elsewhere. Everything will still work but the experience won’t be quite as fluid. The important thing is that all the content is still accessible without JavaScript.

Finally, I wanted to make the page look pretty. I’ve gone for a bit of a mixture of styles. The colours are autumnal and there’s a floral background. The navigation has a kind of bookish, classical feel to it but the pages themselves have been slightly grunged up.

I had a lot of fun making this little app. At times, I was positively grinning with glee as I programmed the latest addition. I really enjoyed being able to use so many different technologies at one time: PHP5, Web Services, XML, XSL, OPML, RSS, JavaScript, DOM Scripting, Ajax, XHTML and CSS. Personal projects like this really help me get to grips with ins and outs of technologies that will come in useful on commercial work.

I’m going to keep tweaking the page. I need to investigate how screen readers cope with portions of the page being refreshed. I may add an optional checkbox. Ticking this would trigger an alert whenever new content is loaded. This alert could then notify screen readers to trigger a fresh reading of the page.

Hopefully, it won’t take me too long to write the documentation of the building process. In the meantime, have a play around with my new toy:

Adactio Elsewhere

Warning: this is going to be meta-writing. I’m going to blog about blogging.

Meri has written a great post called Better vs. Different. In it, she follows up some of the issues that Molly has written about. Speaking specifically about blogs, she writes:

"Part of the problem here is the definition of what is seen to be the "good content" of blogs (especially technical blogs) - most of the very popular technical blogs are extremely focused. They are quite narrow in what they encompass, very detailed, even extending to code samples a great deal of the time."

This is something that I’ve noticed before and it’s always bothered me slightly. I can see why focus is good but it can also be somewhat alienating.

If someone only ever blogs about web standards, I’m only ever going to see one facet of their life. That’s fine. I’m sure that many people quite deliberately want to show just one side of their personality to the outside world.

But to me, personal publishing has always been about connecting with people on a more personal level. I must admit that I get squeamish when designers and developers talk about how great blogs are as a tool for getting noticed professionally. It’s true but the danger comes in allowing that you dictate what you publish online. My gag reflex kicks in whenever I hear that words "leverage" and "blog" in the same sentence.

Don’t get me wrong: blogs can be great resources for finding solutions to technical problems as well as being somewhere where technical issues can be discussed. It’s just that the emphasis in the term "personal publishing" is shifted away from the personal and more towards the publishing.

Personally, I’ve always enjoyed blogs that veer wildly from topic to topic. Most people are very multi-faceted and I like it when that is reflected in their online writing. People like Molly and Jessica spring to mind. As Meri rightly points out, this more open, honest style of blogging seems to be more common amongst women:

"Women multitask. Don’t tell me men do this to the same extent - I love guys and I work well with them, but they can’t juggle anywhere near as well. Because we multitask, we’re more likely to fall into the hybrid blogger category - writing about all the things that interest us."

I enjoy using this journal as a lens that focuses what’s going on in my life and projects those things on to a web page. I know that lately I seem to be writing about purely technical stuff but that’s only because lately, that’s all I seem to be doing. I hope that my usual random waffling will recommence soon.

To be honest, the grab-bag nature of my writing is one of the reasons why I don’t have comments here. I think comments can be great for building an audience but I’m not so sure they work for audiences, plural. In my experience, comments work best on the really focused blogs. In fact, I think comments can act to actively narrow the focus of blogs that were once broader in scope.

Still, I can see their value on selected posts. Maybe I’ll introduce comments on some of my more techie posts. I just don’t want to hear any complaining when I start posting movies of puppies.

There are a lot of ways of tracking up-to-the-minute memes on the Web right now. You can check out what’s hot on Technorati. You can find out what’s popular with Del.icio.us.

But really, you can’t beat a good ol’ punch up.

That’s why, when I idly wondered which was the more powerful buzzword; Ajax or Folksonomy, I turned to GoogleFight.

Who knew? It’s Ajax by a knockout.

A little while back, Derek Featherstone started a discussion about what he called browser elitism. There were some interesting and very revealing comments.

Derek realised that the issue needed some clarification and he posted a follow-up. His basic question is this:

If you are adding a usability enhancement to a site, is it ever okay to deliberately exclude a specific browser from receiving those enhancements?

The issue is somewhat clouded by the fact that "a specific browser" is usually Internet Explorer. There’s no love lost between standardistas and Microsoft.

Derek gives some specific examples:

"A form field receives focus and is "highlighted" as the active field using the :focus pseudo-class."

"When hovering over a checkbox or radio button and its label, you add in a background-color to the pair so that their association is more closely understood."

And so on. All of the examples have a common theme. They all use CSS2 pseudo-classes. This reminds me of something I’ve mentioned before:

Why is it acceptable to use CSS (which handles presentation) to add behaviour to a document? Surely that is the domain of DOM scripting?

Pseudo-classes like :focus and :hover are basically event handlers… event handlers with really patchy browser support.

The idea of separating structure and presentation is deeply entrenched in CSS based design. Separating structure and behaviour with unobtrusive JavaScript is also widely regarded A Good Thing. Yet the very developers that are flying the flag of web standards have no qualms about mixing up presentation and behaviour.

Is there some kind of double-think at work here?

I think there might be a simpler explanation.

CSS is more widely used and understood than JavaScript and the DOM. There is a general feeling that things can be accomplished quickly and easily in CSS that would take longer to do with DOM scripting.

I think this belief isn’t based on the reality of developing with the DOM. Rather, it’s part of the FUD surrounding JavaScript in general. It is still considered by many to be a nasty, inaccessible technology.

This view is outdated and fundamentally flawed but it does explain why developers so readily destroy the separation of behaviour and presentation with pseudo-classes. The CSS route is perceived to be quicker and easier.

There are two problems with this conclusion. The first is that just because something appears to be easier, doesn’t make it the right tool for the job. In fact, there was probably similar excitement when the <font> tag was introduced to HTML: a quick and easy way to control presentation.

When we evangelise CSS based design, we often hear a refrain from old-school designers who claim, "but it’s easier to use tables!". As it turns out, using CSS is, in many ways, easier than using nested tables and spacer .gifs. The problem is a fear of a new technology and a misplaced belief that it will be more time-consuming.

I’m seeing exactly the same attitude now being expressed by CSS designers who don’t want to learn DOM scripting: it’s too difficult, it will take too long.

The second problem with using pseudo-classes as event handlers is more practical and relates directly to Derek’s question. CSS2 is not supported evenly across browsers. Some browsers have much better support than others.

The DOM, on the other hand, has pretty great support across the board, certainly for the core methods and properties.

In light of this, Derek’s question takes on another dimension:

Knowing that the supposedly easier solution will exclude more browsers than the correct one, is it okay to exclude those browsers?

There are three fundamental points here:

1) DOM scripting, not CSS, is the correct tool for making behavioural usability enhancements.

2) Amongst browsers, the DOM is more widely-supported than CSS2.

3) Amongst developers, CSS is more widely-supported than DOM scripting.

To me, it’s clear that the problem lies with the third point. Lots of developers use the hammer of CSS so everything looks like a nail to them.

If you’re a web developer and there’s a usability enhancement you could potentially add to a site you’re building, think about the options. The most popular option is to try to use CSS because it’s what you know. You might claim that it’s financially impractical to attempt to accomplish the task with DOM scripting: it would take longer and therefore cost the client more.

That’s the problem right there. There is a gap in your skill set that needs to be filled. It’s time to expand your toolbox.

It’s about time we stopped blaming poor CSS support in browsers when the real issue is poor DOM scripting support in developers.

As I said, this issue is somewhat clouded by the specific browsers involved. As Derek says in a corollary to his question:

"What if input:focus and tr:hover worked in IE, but not Firefox? Would you use DOM Scripting to add support for them in Firefox?"

In theory, the specific browsers shouldn’t matter. Wasn’t that the whole point of web standards? No more coding for browsers. Now we code to the specs instead.

Well, the W3C DOM is a spec. It’s a web standard, just like CSS and XHTML.

This isn’t about browsers. It’s about web standards. It’s about using the right tool for the job.

I took some time out yesterday to attend a little literary event. The authors Rupert Thomson and Andrew Miller were speaking and reading at The Old Market, which is right at the end of my street.

I know Andy and I’ve read his Booker-nominated Oxygen. I wasn’t familiar with Rupert Thomson’s work. I intend to become more familiar with it. I bought his new book, Divided Kingdom, after hearing him read the first few pages.

The reading was enjoyable but it was the speaking that really held my interest. The two authors chatted about their respective writing processes.

Both writers said they did very little planning or outlining for their books. They did plenty of research but they certainly didn’t wireframe the plot or the characters. Rupert Thomson likened to process to sculpture, carving away at a block until something emerges.

With a process like that, there can be plenty of dead ends. There were nine very different drafts of Divided Kingdom before the final novel emerged.

During the question and answer session, I asked what seemed to me to be the most pertinent question:

"How do you know when you’re done?"

There’s no quantifiable answer, of course. The secret is knowing when to stop. If you go too far with a sculpture, you might chip away until nothing is left.

It was quite gratifying to get an insight into the creative process from a discipline other than web design. At heart, the disciplines aren’t all that different. Both of them exhibit a 99 percentile in the perspiration to inspiration ratio.

I wish I could just design something great straight off the bat. It never seems to work that way. Instead, I have to pay my dues by investigating and discarding countless design directions. It’s usually right at the point when I’m ready to give up that something clicks and I suddenly "get it". It’s then I know that I’ve found the right design (strange that I would call it "finding" the right design… as if I didn’t create the design myself).

My design process isn’t the fastest. I usually end up with a folder full of discarded Photoshop files. But I know that, without those dead ends, I never would have arrived at the final destination.

This process had never been a problem until recently. I was working for a client on an hourly basis. The client questioned the hours listed on the invoice that I claimed to have worked. Looking at the final design I had produced, he couldn’t see where the time had been invested. I offered to show him my folder of discarded designs but he didn’t seem interested.

I think my process might be similar to what Jeff Veen calls blinking out design:

"The problem, of course, is doing this commercially - doing it on cue. How do you write a proposal that suggests that I’m going to "do a tremendous amount of homework, then just wait for the answer. Oh, and it’s going to be really, really painful as we wait. Really painful. Sorry.""

Listening to the two writers describing their craft, I realised that my process wasn’t anomalous.

I’d like to just clear up a few small points just in case there is some misunderstanding.

When I spoke about fixed width and liquid width layouts recently, I don’t recall ever saying:

"Liquid rulez! Fixed is teh sux0r!"

I don’t think any reasonable web developer would suggest that one method is completely right and one method is completely wrong. Instead, the intelligent stance is "it depends".

As Molly so succinctly puts it:

"The context of the design is what will decide."

This is the attitude that any sensible web developer will adopt. My point was this: I don’t see that theory being followed through in practice. It seems to me that most sites are built with fixed width layouts by default.

Now, I don’t know whether that is the right or wrong decision for any particular site. My concern is purely about how that decision is reached. I have the strong suspicion that many people are choosing fixed width layouts simply because it’s the done thing.

I’m worried that the reason for choosing fixed width layouts could become circular:

"Most sites are built with fixed width layouts, therefore I will build my site with a fixed width layout, thereby increasing the number of fixed width layouts."

Sometimes this kind of emergent consensus can be a good thing. But it clashes head on with Sturgeon’s Law, which simply states:

"Ninety percent of everything is crap."

The principle certainly holds true for the web. The majority of websites are built with invalid, hacky markup.

Anyway, that was the concern I was trying to express. I wasn’t trying to suggest that liquid layouts are always the right thing to do. There are strong arguments for using liquid layouts and it seems to me that very few people are making them. If nobody talks about liquid layouts, how will anybody know whether or not to use them?

The theory that the "fixed or liquid" question should be answered on a site-by-site basis is a very sound one. But it only works if the benefits and drawbacks of both approaches are clearly understood.

Developers are more familiar with fixed width layouts because they are so prevalent. The benefits and drawbacks are clear. Knowledge of liquid layouts, on the other hand, has almost become arcana. There’s a lot of FUD floating around out there on the subject.

Somebody needs to talk about this stuff more. If that somebody is me, so be it. But that doesn’t mean I’m a zealot.

I’m not "pro-liquid" or "anti-fixed". I just want to redress an imbalance of information.

If the majority of sites were built using liquid layouts, I’d probably be arguing the reasons for considering fixed width layouts. As it stands, fixed width layouts don’t need anyone to champion their cause.

Liquid design, on the other hand, needs more people like Richard Rutter and Nick Finck. Sign up now - your web needs YOU.

Good design doesn’t draw attention to itself. Really good design is invisible.

Sometimes, really good design can go unrecognised precisely because of its transparency.

In the field of the web design, there is a tendency to laud good visual design. This isn’t always the measure of a successful overall design. But it’s a lot harder to quantify a design that enhances user experience. It’s difficult to award designs to sites that “just feel right”.

Occasionally though, it’s possible to pinpoint the little details that form part of an overall design strategy.

Just recently, I found myself at the site of Cody Lindley. I had visited the site many times before. I’ve always found the site very pleasing but it was only on my most recent visit that I noticed that the site sported a liquid layout. The fluid design was so well executed that I had never noticed it before. Its transparency is a testament to its success.

I was chatting with Sergio. He told me something that I took as a great compliment. He was at my site and noticed for the first time that I was using a liquid layout. I felt warm glow of pride (I guess he noticed I was using a liquid layout because I keep harping on about the subject).

I mentioned my recent similar experience. I also mentioned that I only recently noticed that Jason’s site uses a liquid layout. Sergio hadn’t noticed that either (I believe his exact words were “Jason’s liquid??? wtf!!!”).

Jason’s site successfully combines the visible (gorgeous visual design) with the not-so-visible (a usable liquid layout). I wish there were more examples of that.

I’m putting together a little folder of bookmarks to store sites that are designed beautifully and fluidly (Ethan, Cameron… you guys are in there too). Maybe I’ll turn it into a Stylegala-esque showcase.

Aaron Gustafson is one smart cookie.

When we first met at South by SouthWest, we started talking about DOM scripting and the cool stuff for which it could be used. He showed me the genesis of a very nifty idea he had been working on during his flight to Austin. I was very excited and wanted to write about it straightaway. But Aaron said it needed more work and he swore me to secrecy.

I’m pleased to announce that Aaron’s idea is ready for its close-up.

The problem:

Form elements, particularly <select> dropdowns are notoriously difficult to style consistently cross-browser, cross-platform. Safari, for instance, won’t let you style the widgets provided by the OS.

The solution:

Replace the <select> element and its associated <option>s with a <ul> element contain <li>s. Then add behaviour to the list to make it work just like the replaced form element. Now you can style that list any way you like.

That’s what Aaron has done. He’s written up the process. It’s well worth reading. At the end of it, you can play with the finished result.

I’ll probably end up using this for the style-switcher here on this site. I’m going to hold for now though: Aaron has promised a sequel to his article which will examine all the accessibility implications.

I like the way his brain works.

Slap your PayPal payment down for the latest issue of Design In Flight, the PDF magazine for design professionals and web developers.

Not only will you get to see the funniest cartoon ever by Kevin Cornell, you’ll also get to read a terrific article by Molly. It’s entitled The More Things Stay The Same, The More Things Change. It’s about trends in web design, a topic that fascinates me.

Finally, someone is talking about the elephant in the living room of web standards:

"Visual designers on the Web hunger for precision. It’s something we’ve long been denied, largely due to the fact that the way people access and use the Web is so variegated that no matter what we do design-wise, people are simply going to be looking at our designs using different resolutions, window sizing, and browsers."

"But sometime in the past two years, the reappearance of centered, fixed designs emerged - and from an intriguing place: the Web standards design community."

Now, don’t worry, I’m not about to go off on another rant about fixed versus liquid layout. But let me relate a little anecdote…

During my presentation with Andy at South by SouthWest, the subject of CSS design trends came up in the Q&A. While I was answering the question, I briefly touched on the fixed vs. liquid debate.

After the talk, someone came up to me and asked about this "liquid layout" technique I mentioned. He hadn’t heard of it. Needless to say, I was happy to oblige and I probably bored the poor guy senseless.

He asked if I could recommend any resources on the subject. I didn’t have much to offer him. Richard has some great posts on his blog but generally, it’s not something people talk about.

It made me wonder if perhaps I should be making more noise about the subject.

Y’see, I always assumed that the prevalence of fixed-width sites was the result of an informed decision. I imagined that designers weighed up the pros and cons of fixed and liquid design and then, after careful consideration, chose to build a site with a fixed width layout.

Now I’m beginning to think that this scenario is wishful thinking. Could it be that most designers are simply making the decision based on what everybody else is doing?

If so, that’s a disturbing thought. Decisions as important as that shouldn’t simply be the result of a sheep-like attitude.

This doesn’t just refer to fixed width layout. There’s nothing inherent in CSS that favours gradients and drop-shadows. Yet those techniques are hugely prevalent in CSS-based designs.

Step back and take a look at the bigger picture.

The wisdom of crowds is a nice idea but it can lead to some unfortunate results. The outbreak of pointless Flash intros on the Web was the result of clients and designers thinking, "everybody else has one, so should I".

It’s a scary thing to be the dissenting voice in a crowd. I’m not just talking about the high-profile historical figures like Charles Darwin and Galileo Galilei. What if one person in the Seventies had simply said, "y’know these flared trousers that everyone’s wearing look pretty ridiculous to me"?

So maybe I should be making more noise. I could become the web standards equivalent of those loonies with the sandwich boards, declaiming loudly that the end is nigh.

Or perhaps, if the problem really is a "monkey see, monkey do" attitude, I should softly, softly, catchy monkey. I could speak softly and carry a big stick.

A big… liquid… stick.

For catching monkeys.

Um… I’ll get my sandwich board.

Even before the election was announced, the Tories had been actively peddling their particular breed of populism.

They’ve been filling billboards with tabloidesque statements like, "It’s not racist to impose limits on immigration" followed by their tagline, "Are you thinking what we’re thinking?", using particularly ugly fonts, I might add.

They’re just asking to have the piss pulled out of them, really.

Enter the mighty Stuart, who has prepared a piss-pulling widget for our entertainment and pleasure. Edit the text, choose a font, alter the tagline and off you go.

I couldn’t quite match the subtlety and wit of this clever bit of japery, but this is what always goes through my mind when I see those billboards…

If only this were a server response instead of a message count…

Molly’s been busy lately. Not only has she been interviewing the father of CSS, she’s also found time to put together a table of syndication link locations.

This is in response to the question, "Where is your feed?".

There are a number of issues here. One, of course, is the placement of the link. How visible should it be? What should it look like? Where should it reside on the page; the top, the bottom, the side?

The other issue is how much explanation is provided by the link. Is a certain level of familiarity with RSS assumed? Is the word "subscription" more accurate than "syndication"?

Funnily enough, I’ve been making some changes over the last week to how I deal with feeds on this site.

Up ‘till recently, I only offered an RSS feed for my journal entries. Since becoming a more active netizen recently, I’m now also offering feeds for my Del.icio.us links, my Flickr photos, my Upcoming events and a FeedBurner mish-mash feed.

I’ve listed these feeds under the heading "Subscribe". I agree with Molly that this is a more widely-understood term than "Syndication".

I’ve added a title attribute to each link with the text "copy the location of this link and paste it into a newsreader".

The title text could be easily missed though, so I’ve added another step for anyone who clicks on the links. A little DOM script intercepts the click and cancels the default action (displaying the raw feed). Instead, a pop-up up window is spawned, giving a short explanation of RSS and newsreaders.

This solution isn’t as thorough as simply providing a link to an explanation page but it is nice and discrete. Visitors familiar with RSS will know what to do. Visitors unfamiliar with the format will soon find out.

Mark Cuban believes the countdown to the extinction of CDs is about to begin. He bases this on personal experience:

"MP3 players are changing peoples listening habits. We don’t carry folders filled with CDs anymore. We carry our library in our MP3 players. We don’t listen to CDs. We listen to playlists that we adjust all the time. We don’t burn CDs anymore, it’s too time consuming. We copy all our music to our MP3 players so it’s all available at our fingertips."

Some will be sad to see the death of the CD. Dan says:

"One of my favorite rituals has always been going to the record store and buying a CD or two. The physical act of purchasing something, taking it home, opening it up, lookng at the artwork, reading the lyrics, etc."

Personally, I feel that this is an issue that can be addressed. It might be a non-trivial task but online music stores could provide artwork, liner notes, etc. in a digital format. Richard explains further.

For me, there is a deeper, more fundamental problem with music purchased online, at least in the way it’s being sold now. Mark Cuban hits the nail on the head:

"Do I want to always keep my subscription live? Do I want to store the music in a proprietary format that only a couple devices can use? Those are all tough decisions to make when the only thing I know with certainty is that the device I’m using as an MP3 player today, is NOT going to be the device I’m going to be using 18 months from now."

As he points out, that’s where the humble CD still proves its use. It’s a DRM-free, device-independent storage medium.

Personally, I use CDs purely for their back-up value. When I buy a CD, the first thing I do is rip it to MP3. I listen to my music almost exclusively on my computer and iPod. I rarely use my CD player. At the same time, I’m glad to have the CDs on hand.

Right now, the Digital Rights Management is keeping me from buying music at the iTunes Music Store. If I ever overcome this aversion, I imagine that the first thing I’ll do with my newly purchased digital music will be to burn it to CD. This is really just the inverse of what I do when I purchase music in a physical format, but with the important difference that I now I have to provide the back-up medium. It hardly seems fair that, if I want to secure my music for future use on future devices, I need to stock up on blank CDs.

While music is sold online in any kind of protected format, the extinction of the CD will be delayed.

I can also understand the pleasure that Dan and Richard get from purchasing CDs (or vinyl). Although, for myself, I don’t necessarily need to be in a bricks’n’mortar store.

I’m intrigued by the latest project from Coudal Partners. It’s called The Show. They’re selling limited edition live recordings of bands. They’re selling these recordings on CD.

The marketing and packaging is clearly an important selling point. I clicked through to the page of Dead Can Dance recordings and I got suckered in by the beautiful looking cases and artwork (combined with the knowledge that Dead Can Dance are a great live band). Within five minutes, I had finished the PayPal payment process for a limited edition recording made in Dublin a few weeks ago.

When the CD shows up, I will rip it to MP3, of course. But, for once, I might be treating the packaging as more than just something in which to keep my plastic back-up.