Falling Leaves: the Ardes blog

Archives filed under "blog"

Moving again

Ray Drainville

After a lot of work the old ArDes server has been shut down & the blog has been put on a new platform. It’s a truism about blogging that most posts are apologising for not updating & then explaining the shift to a new platform. This post is no different in that regard. But this is really good news.

I did not relish managing a server myself; and with the recent revelations about security holes in SSH and so many platforms, it sapped a lot of mental energy just trying (trying, trying) to keep up-to-date with server gubbins that you don’t know you have and don’t know are out of date. Plus, running a server is expensive for what you get out of it; and chasing clients for hosting invoices is not my idea of fun. I got into this to make pretty things. Chasing up invoices is not pretty. So I’m happy to have that out of my thinning hair.

Another reason to not write on the blog was to evaluate what I wanted to do with it. We used the Rails-based Mephisto for quite a while, but that has become abandonware. Like managing a server with ageing gubbins, managing an ageing blog is no fun—it presents you with a lot of potential security dangers as well as the worry that it’ll fall over at any point due to a minor update. I’m happy with the change & very pleased with the notion of writing again.

Name Change

Ray Drainville

As of today, we’re changing the name of our company from Argument from Design to Ardes.

Why are we doing this?

There are many reasons for the change. Let’s go through them:

  • The URL for the company’s website has been ardes.com for virtually its entire history;
  • Ardes has always been our shorthand name for the company;
  • You’d be surprised how few people know how to spell “argument”;
  • The connection between the philosophical concept of the “argument from design” & religious people has only grown stronger over the years, and I didn’t want to be associated with that.

That last point deserves a little more explanation. My rather wilful interpretation of the argument from design was that it needn’t be a religious argument, but rather merely evidence of a conscious decision process: that something clearly & beautifully presented was evidence of a conscious hand & not the product of chance. Many people use it in an attempt to prove the existence of god, and that’s become something of an issue for me, because I’m not religious.

Anyway, I’m getting over my head, and the point is that that isn’t what we’re about. We’re all about making beautiful & easily-usable things.

Soon the blog will reflect not only the Ardes.com redesign, but its name change as well.


Ray Drainville

You’ll also notice that the ability to comment on posts has been removed. The subject of site comments has emerged recently. The simple fact is that most comments posted are spam, and while they rarely make it onto the blog, they gunk up the system. Comments are still gratefully appreciated: just use our standard contact form.

You may also have noted that Ian has been quiet for some time. Ian & I split amicably. He left the company to pursue his own projects. They’re incredibly worthwhile: if you’re a developer, I strongly encourage you to have a look at what he’s got up at GitHub. And of course you can always follow him on Twitter.

Do I Like This

Ray Drainville

So, is this blog dead or what? It’s undeniable that there have been few posts on it all year. Why is that?

Part of the silence is due to work: we’ve been busy, and in fact I’ve yet to write up a report on our latest launch. But even when there has been downtime, I haven’t posted here. Instead, I’ve posted to… Facebook.

Yes, Facebook. I regret this now: it’s insidious how it sucks you into its own little world. I don’t want to get into an extended reflection on Facebook, but the promise of speaking to friends is very compelling. It’s just too bad that generally it encourages the shallowest of interchanges—similar to how it devalues the meaning of “friendship”. In any event, I’ve been posting things I like there instead of here. That’s going to stop. I’ll repost on the blog the things I’ve been posting on Facebook.

User Interface Disasters: CMS

Ray Drainville

We have a client that is part of a large institution (both shall remain nameless to protect them). Like many in such cases, they’ve had a CMS thrust upon them. I won’t name the CMS, but you might be able to figure it out from this screenshot:

Look at this from a user’s perspective. OK, we’ve got a nested system of some sort. What are the radio buttons for? We can also delete “publication details” (notice the wastebasket at the right). Below the wastebasket is a tickbox. What does it do? And do you dare click it? How about the “temporary save” button—why is this not automatic, as in online apps such as GMail & Basecamp?

Let’s look at another example:

This second screenshot comes from further down the page, from a list of publications. Clicking the “Switch” button lets you move the publication up or down the list; when you do this, the page reloads. It would reload every time you moved the position of the item (average page refresh time: 30 seconds).

Now imagine that you’re re-organising a list of, say, 20 publications so that the most recent publications come first in the list—a not uncommon task. Imagine that, previously, the publications were listed in order of publications (i.e., that the oldest one was first). To just move the latest publication, you’d have the page refresh 20 times. After each refresh, you’d have to scroll down the page to find the publication again so you could move it up one more position. Imagine that you have to re-order several pages’ worth of publications: now do it a million times!

After doing this for a couple of hours, finally imagine saying “Fuck it, it’s not worth the effort”. You have now reached the position of my client—and, indeed, the position of many people who have had CMSs thrust upon them.

A lot of things have gone wrong here. At my bitchiest I’d say that these screenshots showed the unholy marriage of Windows 1.0-style software design with all the flair of a Linux user interface. How did it come to this? Why was this software chosen? How do you get out of this situation?

I don’t have an answer to that last question, unfortunately—large institutions make their decisions on behalf of all departments & it takes years to move such a big ship. But I know how others can avoid this.

Let’s gain some perspective: CMSs became a big thing before the dot-com bubble burst in the early 2000s. They were designed for the browsers of the day—Internet Explorer 4 & 5, perhaps even Netscape 4. Any web developer will tell you that these browsers are pretty limited—and that support of legacy browsers quickly reduces the options you have to design an intuitive interface, progressive enhancement techniques notwithstanding. So, CMSs were designed in an era when you couldn’t have asynchronously-updatable data on a page—yes, we’re talking AJAX here. In other words, many CMSs come from a less technologically-advanced world.

Mixed in with this is the glacier-like pace of large organisations in their technological adoption. Years ago I worked for a university & saw first-hand why the technological decision-making process took years: often for legitimate reasons. For example, if you are running a corporation with 10,000 computers, it takes a long time to produce all the tests necessary to ensure that you’re not going to bring down the entire corporate system in your enthusiasm to adopt new technology. Accordingly, many corporations start looking at tech products & it can take years for them to reach their decisions. (NB: many corporations are a lot better at making swifter decisions now, but it’s a rare academic institution that has matched this quicker pace.)

So let’s recap: many CMSs were originally built in a time when dinosaurs walked the earth & this is when large corporations might have begun eyeballing their products. Years go by, the corporation makes its (now dodgy) choice & then the corporations’ employees are stuck with the result for years to come—perhaps simply to justify a decision that cost millions of pounds even when that decision clearly was a bad one.

A major part of the problem is the decision-making process: after a certain cut-off point, no other options may be admitted. This is unfortunate (to say the least) because in the meantime blogging software has emerged not just as a niche player but as a robust solution—which solves many of the problems that CMSs were supposed to tackle. Publication control & template-based “unified” branding cross-site are allied with a significantly better interface. Moreover, many blogs allow for “static” pages (in this context, pages note defined by the date of the post but by their content). And while blogs may not automatically provide all the semantics required for, say, publications, most blogging software allows you to delve into markup to address specific concerns—or have plugins that would address the concern—or (as a last resort), you can tag content according to its semantic meaning. It’s a very good solution that solves 90% of the problems which CMSs were to address.

Now this doesn’t leave our clients in a good place—they still have to use a terrible CMS. My question is: why hasn’t the CMS vendor updated the working of its CMS? At the very least AJAX-based tools to move publications (as in the example way above) would ease so much of the pain. A less charitable person than myself would conclude that they don’t care that their software is so broken, so there is little impetus to fix it. A more charitable conclusion would be that they don’t realise that the software is broken. Perhaps when clients don’t renew their licenses they’ll wake up.