Thursday, September 30, 2010

User-centred design

In a follow-up to my previous post on admin interfaces, I thought I’d post on something that happened the other day on the current project.

As part of the ecommerce site we’re building we have a dedicated service for managing email notifications (registration, order confirmation, lost password etc. – about 50 in total), and during development we’ve been using Google’s SMTP service to do the sending itself. A couple of days ago I wanted to find out whether an email had been sent (as it hadn’t been received), and the easiest way to do that was to log in to the associated Gmail account and look into the Sent Items folder.

Turns out, the best logging / admin tool for an email service is, well, an email service. You can search through the emails, filter them, track them, configure various options and more. It just works.

At the same time, whilst thinking through the process for website administrators to take down certain products, the solution is not to give them access to a special website from where they can use the the Take-Down function (for which they will need the appropriate training and documentation), it’s to put a Take-Down button on the website product page that is only visible to people who are administrators. No “process re-engineering” required.

This user-centred design concept may yet catch on…

(Of course, it can get a bit out of hand – qv the “customer journey re-engineering manager” comment in this article - – rather embarrassingly I think I know the people involved!)

Sunday, September 26, 2010

HTTP self-service

HTTP is all around us – it has become the de facto transport protocol of choice; web servers may be the primary source, but routers / access points have used it for a  long time, databases have begun to use it (e.g. CouchDB, RavenDB), and now even console apps have taken to its user-friendly interface. We’ve been using Mercurial on our latest project, which is a fantastic application in its own right, and despite being essentially a console application, it too contains its own HTTP server. Type in “hg serve” at the command line, and it will start up a single-use dedicated HTTP server, which provides a great online user interface.

I won’t go into the details (you can try it yourself), but it did set me thinking. Running background applications on a server have always suffered from the lack of user interface, but embedding an HTTP server in the application would allow you  to offer this**. Moreover, within a locked-down production environment you could provide network access to an application using a protocol that sysadmins understand.

Digging a little deeper, I came across Kayak – a lightweight .NET HTTP server, which would allow just this. It should be possible to use this (or an equivalent)  to bundle an HTTP server in with your services to serve up things like: logs, service status (e.g. databases up, network locations running) & configuration information. This would also allow you to manage / update configuration settings in runtime, and to combine multiple services into a simple management console.

Ultimately, it would be great to provide a mechanism for uploading software updates – in the same way that you update router firmware – navigate to a URL, upload an update package, and then restart the service. Add in scripting support, and it would make management of a multi-server environment much, much simpler, without the need for an expensive System Centre type application.

I’m so convinced that this is a good idea that I’m going to set up a project to demonstrate its application, so watch this space.

** NB – when I say “user” interface, I am obviously talking about the tech-team, not end-users. I’m not advocating opening this kind of interface to the internet – this is internal only!

Monday, September 13, 2010

Whatever happened to XSLT?

Many, many years ago I built a website that used XHTML/XSLT to render all of the pages (this was back in the old-school ASP days). It worked a treat, and I’ve had a certain regard for XSLT ever since.

Which is why I was curious when some colleagues were tasked with building an email template system for an ecommerce system (large ecommerce systems can have dozens of email templates covering things like order confirmation, registration, forgotten password etc.) and then decided to use their own custom templating language.

Surely this is what XSLT was invented for – taking one block of XML (e.g. order details) and transforming it into another (an XHTML representation of the order)? “Too hard” came the reply; “it’s another language to learn” was another.

I wondered if this was a wide-spread complaint, so did a quick Google, and it appears as if XSLT has dropped into a black hole. It’s either so ubiquitous that no one talks about it anymore (it just works), or people are genuinely turned off by it.

It’s a shame, because with all of the fuss about DSLs these days, XSLT deserves an honourable mention.