Over the last few months we’ve moved all our online projects away from Dreamhost and over to Amazon Web Services. It was a steep learning curve of various sysadmin tasks but we had outgrown Dreamhost by some margin and had dealt with enough poor customer service to make it satisfying to leave.

There have been some immediate and obvious benefits. It would have been extremely difficult to build IMPS3 on Dreamhost for a start. The Open Voice Factory hasn’t had as obvious a change, but it now runs faster and I’ve got much better access to build it up.

We’ve been migrating other projects away from Dreamhost for some time. Static sites like Flowers For Turing and Project Real have been hosted on Github Pages for a while. That has the advantage of being free, and letting any passing nerd pop by and create a pull request to fix any typos or errors.

The migration isn’t yet complete – itself remains on Dreamhost – there will be a final tidy up in the future.


We’re doing our second field trial of IMPS3 this week. This trial was the first one done with a school rather than a university, and the first time we’ve run it without Joe, who wrote the code, on site.

I’m really optimistic about it – I’m looking forward to a new age with our writers feeling much more in control, much earlier in the process. Not to mention – it being easier to access on school IT systems.

So far the trial has gone extremely well and we’re hoping to roll it out as standard in the next couple of months.

CommuniKate Link Up

One of the projects we maintain is CommuniKate. It’s an open-licensed page set for use in AAC devices. Notably, it was the first such page set and thus gets used in lots of small (and large – see e.g. Optikey) open source AAC software systems.

We got a lovely message last week to say that it had been used in a new webapp called Life Companion, and, as a bonus, has been translated into French.

Notice of maintenance for the Open Voice Factory

We’ll be moving the Open Voice Factory from one hosting provider to another on Tuesday the 29th March.

  • There might be momentary disruption to users who are using the current version of our client (which runs on a different network anyway, but *does* access files on our server.
  • There may be longer disruption for very long-term users of our original web client. It shouldn’t last more than a few moments.

Notice of maintenance for the Open Voice Factory

We’ll be moving the Open Voice Factory from one hosting provider to another on Tuesday the 15th March.

  • There might be momentary disruption to users who are using the current version of our client (which runs on a different network anyway, but *does* access files on our server.
  • There may be longer disruption for very long-term users of our original web client. It shouldn’t last more than a few moments.

(This didn’t happen because the person who in charge go covid so has been postponed)

Risk Assessment

We’re planning on moving The Open Voice Factory to a new server in a few weeks. and so I’ve reviewed and updated the Risk Assessment for the software. You can read it below.

We’ve always had a very very very hands-off attitdue to data for the Open Voice Factory – we don’t collect data on if particular aids are used or not, or how much. (we’ve recently started to monitor the generation site itself). We also try and be ultra smooth – you don’t need a username or password to access the site and we don’t collect any sort of information at all about people other than when people email us with technical queries.

All of which makes it quite difficult to warn people that the site might be offline for a while during the handover. Particularly when many of our users are from outside the UK (judging solely by the contents of my email inbox. The international aspect also makes it not obvious *when* to do the changeover. If I could garrentee everybody was in the UK then I’d throw the switch at 3am.

Now, if this is done right, there won’t be a break in service to worry about, and it’s very unlikely to affect many people (not least because I believe most of our recent use has been from people converting files into obz files for use in applications like Opikey) but it should be taken seriously.

Our very own writing platform: IMPS 3

This week we published a book and used a new experimental (and very cool)

collaborative writing platform to do it. 

On Friday we published Catherine’s Canvas. It was written by a group of creative writing students at UCLAN, and it’s a dark tale of murder and abuse.  It’s always awesome to watch writers grow as they put together their novel and it’s pleasantly different when it’s university students – they are less taken with the ‘wow’ factor than secondary school students, and the technical changes are more subtle (but, amazingly, still there) but there is a definite change in their mindset.

While I always like seeing a group develop over the course of the week, there’s more news: this week was the  first trial of IMPS3.

“What’s IMPS 3? For that matter, what’s IMPS?” you might reasonably ask.

IMPS is the technical backbone of the White Water Writers project. It’s the software that sources all the different files that the authors write in, combines them, analyses typesets them, and produces the print-read pdfs and epubs that are uploaded to Amazon at the end of our writing weeks.


The first version of IMPS was cobbled together from odds and ends in about 2009 and randomly updated whenever an error occurred or a need arose. It first accessed the writers’ text in a custom wiki and then moved on to using Google Drive.

The second IMPS 2 was launched last year, when we started moving our servers to AWS.  It is a much more stable, much happier system, and it added features like native ebook creation.  It follows the same basic structure as IMPS 1 and is even mostly the same code, but updated and refactored into something a bit easier. It also relies on Google Drive as a front end.  

What’s different about IMPS 3?

IMPS 3 is written entirely from scratch and it has let go of Google Drive in favour of our own editor (under the hood it’s using the etherpad engine). So we now have our very own collobartavie writing platform.

Compared to IMPS 2 it is blindingly fast (I wrote a script that used IMPS 2 this morning and was amazed how it suddenly seemed to drag) .     

This week was the first time I’ve let real writers use IMPS 3, and I was waiting for a fairly advanced group for two reasons:

  • In case it went wrong
  • Because they would be a challenge for the code.

I’m pleased to say that the code held up and the writers got to play with completely new features like: 

  • their own dashboard for their character;
  • new ways of viewing structure; 
  • a new ordering system that makes it easier to move, discard, and reorder scenes.

There is still work to do before I can deploy it to all camps: while it’s stable enough for me to use, it’s unfair to give it to other camp leaders yet. I’ve got a long list of improvements to make.

Does the software you use really matter?

Yes, because tools shape stories. We ask our writers to do a monumental thing: write an entire novel in a week. And the more we can support them, the better they do and the more they grow.  If we make it easier for them to see plot holes earlier then feel safer encouraging complex twisting plotlines. If we make it easier to quickly reorder scenes then we make it easier for our writers to really think about the rhythms of the novel.

Why is it called IMPS

It’s the Infinite Monkey Protocol Suite (IMPS) and is based on the ‘real’ (although published on 1st April) protocol  here

The abstract from the document includes:

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters

And so you can see why I took the name when I wrote the code.

Landing page

We ran a Google Optimize test over the last month. We tested four variants of the White Water Writers homepage to see which one was most ‘effective’. In this example ‘effective’ means ‘sent people to the contact page’.

The result was fascinating.

So, when we started the test, the White Water Writers landing page had some text, and then two buttons, one to click if you are a student, and one if you are a teacher. (The student one goes to a page that encourages students to tell teachers about the project, because it’s the teacher that needs to book with us).

The four variants we tested were:

  • The original version.
  • A cut down version of the introduction text
  • The introduction text was replaced by some introduction text we wrote for a grant recently.
  • The removal of one of the buttons so that users only had one change.

Here’s the results:

Original converted 6%, Grant proposal text converted 1.6%, the 'less text' version converted 4% and 'just one click' converted 9%

There isn’t much in it, but the ‘just one box’ outperformed the others. This was completely unexpected; the idea of having two boxes was because we thought people prefer having some level of choice.

Now, it’s literally only one user making the difference between two boxes and one box, so there isn’t much in it. But given that we went to extra effort to give the choice, it’s amazing that they are on par.

However, that’s not the full story. It turns out that the ‘bounce rate’ (the percentage of people that looked at the page and then immediately left) for the ‘one box’ version was 70%, compared to 50% for the normal one. That suggests that more people were at least exploring the site

Now let’s look at more data:

VariantExperiment SessionsPages/SessionAvg. Session Duration% New SessionsBounce Rate
From grant proposal622.3200:01:0777.42%46.77%
Less text512.6300:01:3086.27%45.10%
Just one click box461.8500:01:2080.43%69.57%

So, it looks like in terms of ‘getting people to spend time on the site and look around’, the ‘less text’ version is doing best, even if those people aren’t actively making it to the ‘contact’ page.

This is muddy right? Depending on how we judge the ‘value’ of visits, any of those variants could be the ‘right’ one.


Here’s the conclusion I came to – the homepage isn’t the problem. Four different versions of it (some quite drastically different) didn’t meaningly affect results. If we want to increase the number of students who do this wonderful project, then we have to get it in front of teachers and the front page of the website isn’t what’s stopping them. We’ll run more tests on other sections, and look into how our Google Ads is (or isn’t) working. In the meantime we’ll do what we’ve always done – do good work in schools and rely on word-of-mouth.