torchbox

I've been blogging for a few months now over at the Team Drupal Tumblr. This is one of two tumblrs that Torchbox has set up to serve the internal and external needs of its tech teams.

That means I haven't been blogging much over here. So some of my highlights, if you're interested:

• My talks on all aspects of Drush as "command-line Drupal" at Drupalcamp Oxford
• Another talk about our rebuild of the Love Food Hate Waste website, given at the Oxford Drupal Users Group
• Programmatically executing Drupal Views (may only be relevant to Views 2.x)
• Removing data permanently from a git repository and a related Stack Overflow solution I finally came up with myself
• Bundling the Less CSS module with an install profile

It's probably of greatest interest if you like Drupal; less interesting otherwise. But do wander over and have a look if you get a chance. I might try to duplicate some of the content here, for reference purposes if nothing else; we'll see how that goes.

Wednesday 15 June is but six days away now, so if you're in Oxford you should make sure you have Oxford Geek Night 22 in your diary for that evening. Not only are my employers Torchbox sponsoring as always to make sure it's free entry, but Historic Futures are putting some money behind the bar, enough for a free drink for every geek. Doors open at the Jericho Tavern from 7.30pm, so get there early to make sure you nab a pint or similar before the thirsty geeks work their way through it all.

Even as I speak, our two keynoters are girding their loins and exercising their generic-brand presentational software for the benefit of Oxford's finest geeks. Louise Crow will mark the very welcome return of mySociety to the Jericho's stage by talking about their forthcoming project Fix My Transport. Next up will be Tyler Tate, UX lead and designer, who wants us to look at how people learn, and apply that knowledge to improving usability for everyone.

We've also got four excellent microslots to look forwards to, volunteered by four plucky Oxford(shire) geeks. They're a mixed bag of subjects as always, and we'll also have the even more mixed bag of The Pitch, our sixty-second open-mic slots. Anyone can use these to announce or advertise whatever they want for a minute. There are also still a few spare Pitch slots left, so if you've got something you want to get off your chest, email ogn@torchbox.com to reserve one.

Right. Only six days to go and I haven't even printed posters yet. Or done any of a dozen other things I need to get done before then. What am I even doing, still writing this stuff? I've got work to do. Now clear off and I'll see you on Wednesday at OGN22.

Over on the Torchbox blog I've written about the fact that I'm going to DrupalCon Copenhagen, which is happening all next week. There's not much to add here except that if you're in Copenhagen, and you see someone who looks like me, then do say hello.

I've finally recovered from this week's Oxford Geek Night 13. As usual, it seems like everyone had a great time; as usual, I was running round too much to notice. Free drinks from the Guardian Open Platform almost certainly helped.

As usual the talks were a really high standard, with great keynote talks from Andrew Walkingshaw and Bruce Lawson. And while the previous midsummer OGN was pretty quiet, this time the Jericho was practically heaving. The crowds came in quite handy in the end, as only a handful of people noticed when the beercrate step onto the stage disappeared from under my feet as I was climbing up it, and I landed in a clumsy heap back on the pub floor. That Fentiman's ginger beer is powerful stuff.

Anyway, in a fit of organizing I've also booked the next two OGNs for Wednesday 23 September (OGN14) and Wednesday 25 November (OGN15). Anyone wanting to do a 5-minute microslot talk at either of these should submit the details as early as possible. Sixty-second open-mic Pitches can be communicated via any medium: comments here, separate emails or messages on Twitter (@jpstacey).

(Thanks again to all the sponsors: Torchbox, Guardian Open Platform, Friends of Ed and Moo.)

EditInline was first discussed here. It's a Drupal module that provides your site with handy editing links, inline with each node title, which rather than taking you to a separate editing page use a lightbox overlay on the current page to provide an inline editing interface.

It's currently in alpha but available under GPL on the Torchbox public subversion repository. I've recently prepared another alpha subversion release, so if you want to have a look at EditInline ɑ-0.2 then feel free to download and let me know what you think.

(The main improvement from ɑ-0.1 is a dedicated form workflow for editing inline, which results in submission of the form leading to the lightbox overlay being automatically closed. Future releases should include CSS hooks into the lightbox content and other usability improvements.)

It's heartwarming, really encouraging to see that Drupal 7 is undergoing a usability review. Drupal's a massively functional CMS, but all the functionality in the world won't help you when the average (for which read: can't write HTML, let alone PHP) CMS user can't discover it. There's a common misconception that usability is the finishing touches you add to an application if you've got time, the icing on the cake; but if your application lays any claim to maturity then its usability is the cake, and all that functionality you were so proud of is, without usability, just eggs and flour.

One of the main usability improvements suggested by the usability team---and largely shouted down by the technical team---is the ability to edit inline on the page: that is, to log in as an admin, then have any bit of the page "active", so that if you click on it then it becomes an edit box with the text inside. Flickr does this especially well, letting you edit title and description on photo pages and lists of photos by just clicking on the apparently uneditable text. But Flickr has the advantage that there's very little form on top of its content: it's a delivery mechanism for the raw metadata about photos, and the photo itself.

The other end of the spectrum---which complex CMS sites have every right to sit on---is a rich and complicated mapping between the storage of a node's content in the database and the eventual display of it in the browser. take a page from a recent Torchbox project at random, how would you expect areas of this page from the Joseph Rowntree Foundation's website to behave when you clicked on them? If you have to hardcode print statements in your PHP templates, what do you print? How do you get editing inline to work? What happens when content is brought in from other, related nodes, and mixed in with the other content before display.

I can appreciate both sides to this story of user experience versus technical practicality, although it's not sufficient to expect the usability team to discard the idea merely because there's no correspondence between page content and database content: that's only an argument for why Drupal doesn't currently have edit-on-page. The usability project is moving forwards rapidly, and while there's clearly a tension between usability for the CMS user and feasible technical limitations---usability for the developer, if you like---it will need to be resolved soon for this marvellous work, and a great opportunity, not to end up wasted. And resolving that conflict will involve some sort of compromise, for both sides.

One possible compromise would be to offer edit links, when Drupal can spot a sort-of 1-to-1 correspondence between a fragment of page content and the node that supports it. Page templates and views---specifically hook_preprocess_node and hook_views_pre_render---know full well that what they're processing is a node. And they generally know what field the node title will be in. So let Drupal rewrite the title, to add an "edit inline" link. If anyone clicks on this link, then pop the node-edit form up in a lightbox for editing.

Here's some screenshots of what I've been working on, in an attempt to get people interested (click for bigger.) Firstly, here's what the anonymous site visitor sees:

Next, here's what happens when a user has just logged in. Note that the brilliant Admin menu module kicks in, giving the user a black navigation bar across the top. But, more pertinently, each node title also now has an "[edit inline]" link beside it:

If the logged-in user clicks on one of these new links, then our edit-inline module kicks in and, using the equally brilliant Drupal Thickbox wrapper module, provides a stripped-down version of the node-edit page in a Thickbox overlay, both speeding up node editing using AJAX calls and also letting the user cancel the node-edit procedure and return to the webpage they were on quickly:

To reiterate, you don't have to be on a node's page to edit it. All that matters is that the title of the node you want to edit passes through onee of the supported pre-render hooks. Currently, clicking on save/preview/cancel takes you elsewhere rather than being trapped within the Thickbox, and we're also wrestling with getting CSS and Javascript into the Thickbox overlay to support the nattier bits of node editing, but it's functional and, I hope, gives you some idea of how it would all work given a few more hours of bashing away at keyboards.

Anyway, there it is. A possible compromise. I've mentioned it in a comment on the d7ux blog but I fear I might have been eaten by a spamtrap. If anyone's interested in the project then email me, jp.stacey, either at gmail.com or torchbox.com, and say hello.

People at Torchbox, both singly and as a company team, are committed to helping fight climate change. As a web company, we think we can help most (in our small way) by helping our clients, especially environmental charities, fulfill their potential on the web, and by encouraging green behaviour among our staff: cycling breakfasts, cheap-bike schemes, car sharing, not flying to meetings or on work jollies.

Still, fighting the good green fight can feel pretty lonely, and sometimes you forget not just how many people are on your side in the next office or town, but also of the billions of people who have something to lose to climate change. So as a bit of fun, and to remind ourselves what it's all about, we've recently given the green finger to climate change. Here we are, doing just that:

Want to join in? You can respond to the original YouTube video.

As a result of building a website for a Torchbox client, I came up with a Drupal 5.x module to query the Postcode Anywhere and MailBuild webservices (if they look like an unlikely mix, don’t worry: they’re not coupled together generally, so you can use one without the other). I’ve been meaning to make it live for ages, but never got round to scrubbing the client’s data out of it. Now that we’ve unearthed the module for other work then I’ve finally finished cleaning it.

First, a bit of background. Postcode Anywhere provides a per-lookup paid webservice, converting UK postcodes into valid house names/numbers, streets, towns etc. It allows you to accept a user’s submission of a postcode to e.g. a signup form, then present them with a list of sample addresses, rather than them having to fill in all of their address details.

There’s only really one method exposed for the PA functionality, and it takes a text postcode and returns an array of results:

$data = pamb_pa_get_bypostcode($postcode);

MailBuild and CreateSend, on the other hand, provide a way to store email lists and send newsletter campaigns to subscribers. However, our client also wanted to use it to store snail-mail addresses, so they could use it for both requests for printed matter and also to keep subscribers up to date via email. It was possible to implement this using custom fields, of which the service permits around a dozen: address line 1, address line 2 etc.

There’s an existing Mailbuild module, which technically does the trick, but it’s overkill compared to what the client wanted. pamb’s integration is essentially just “push”: it passes the results of a form submission to CreateSend, by using a template (the one you’ve moved to your theme directory) to “theme” the data as an XML packet. If there are no problems then the system returns nothing; otherwise, it returns a structure of data including the HTTP response and the SOAP packet from the request.

Here’s some sample code:

/* Send SOAP packet */
$no_probs = pamb_mb_send_soap($form_id, $form_values);

/* If OK, set a generic message and redirect: the redirect will pick up
on the generic message and know all has gone well */
if(!isset($no_probs)) {
  drupal_set_message(t(AUTO_SUCCESS));
}

/* If not OK, $no_probs contains the diagnostics */
else {
  /* do something else */
  drupal_set_message(t(AUTO_ERROR));
}

For now, for want of a better name, the module is called “pamb.” And [edit] the code is now available on Sourceforge under the GPL: that should make it compatible with Drupal’s core licence.

1. Download pamb: currently only available in subversion, but clients exist for Linux, Windows and OSX.
2. Unpack it into your modules directory
3. Edit the defines at the top of the file for your own Postcode Anywhere or MailBuild/CreateSend accounts.
4. Stick the pamb_soap.tpl.php in your theme directory
5. Switch on the module in the admin interface

You’re now ready to start developing with its handful of functions. Feedback more than welcome, as given Drupal’s minimal support for mailing-list functionality in core it’d be good to make this into a fully-functional module for similar third-party contact services, and even port it to 6.x.

[edit 2008-06-17: now hosted on Sourceforge]

Torchbox (where I work) soft-launched The Carbon Account today. More press information should be available on the site in the next couple of days: just ring up or email if you need some in the mean time.

Beta testers have been hammering away at the Carbon Account for ages to make sure everything’s working right. The Facebook application has been live a week or so to people involved in beta-testing, and the nascent Wychwood CRAG has been using the Carbon Account as its platform of choice, monitoring and comparing each member’s carbon footprint for a couple of months now. That’s been especially useful, as the CRAG has argued about the functionality and design decisions a good deal from a whole range of viewpoints: from environmental newbies to astonishingly well-informed amateur-experts.

A lot of preparation has gone into today’s launch, but although I’ve been using it for nearly a year, I’ve not been directly involved in the development of the Carbon Account so can’t take any share of the credit. Everyone who has worked on it deserves a big pat on the back today, though. The rest of you, sign up!

The fifth Oxford Geek Night is shaping up to be a really great night. Following on from our keynote confirmations, we’ve now got a full house of microslotters.

Not only that, but we’ve also sorted our extra sponsorship. Joining the ever-indulgent, ever-understanding Torchbox are Google and Friends of ED. In return for sponsoring us, Google have asked us to contribute a post-OGN article for the Google Code Blog, a request which would have been churlish to refuse. Friends of ED will be providing us with another book raffle, which is basically meant to keep people hanging around till the bitter end in the hope of free stuff. We’re of course always open to new sponsorship opportunities, so feel free to get in touch (me, of all things, at jpstacey.info) if you’ve got any ideas.

If you’re interested in coming along, you can let us know on our Upcoming listing, as that lets us keep track of interest. Either way, tell your friends; blog about the geek nights; most importantly, come along!