Loving this Vid

Call me geeky, but watching these two systems interact makes me happy. Here is a short video of Editoria round-tripping a Word file to INK, where it is converted to HTML, and loaded into Editoria….

It pretty much uses the full stack of softwares we have built including PubSweet, INK, Editoria, and XSweet. Love love love it.

INK Vids

Demos made by Alex Theg as a backup for demonstrations (in case wifi fails etc). They have no sound and merely display the core INK features at work.


Creating a Recipe from Existing Steps

INK and Editoria Working Together

Hi Honey, I’m Home!

I’ve been sick the last week and slowly on the way to recovery. Thankfully today I was able to pick up some manuka honey that comes from the hives I have on my property in NZ. The hives are looked after by the good people at Coogzen Lodge down the road and I get a % of the honey produced. Works for me…seems this year they harvested 85kgs of honey, which means I get 10kg!


The honey is manuka, which is the best honey ever. Legendary for its healing properties but also just the best tasting honey around. Pictured here are the actual manuka bushes that the bees have been feasting on.


And a quick shot of the hives, note the young cabbage tree in the foreground!


I just had my first lemon and honey drink for the season. Feel better already!

A Proposal for Cabbage Tree 2.0

The following is an outline on some new tools for the Cabbage Tree method. These proposals are designed to:

  1. Explore how the Cabbage Tree Method (which is largely about facilitated product design and places the user, as a use-case specialist, at the center of the solutions model) can scale its processes
  2. Generate some learnings to help iterate towards a Cabbage Tree model that can also build community

After taking this to the Shuttleworth Gathering, and then unpacking early thoughts at the PubSweet Global Meet, I proposed that we experiment in a series of iterations to extend the Cabbage Tree Method and generate new ideas. Everyone was open to it and so we will try a first experiment, and then reflect on it and iterate forward.


So, a brief framing.
Current Open Source community driven solutions models look something like this:

Developer ------------------------> User

In this scenario, the User is slightly parasitic and the naming is right. The user uses the product of the developers.

In the Cabbage Tree Method, we have re-positioned the ‘user’ as a use-case specialist. They reside at the beginning of the process.

User ------------------------> Developer + UX expert

The user (use-case specialist) designs the product and then the developers and UX people improve the design, and build the product.

What has been pointed out to me (in Athens), is that the developer is featured in the Cabbage Tree Method (CTM) at the beginning by me -since I am the facilitator of the design process and I have some technical knowledge. So the Cabbage Tree Method was born already with a model that isn’t as purely user-centric as it proposes. I’m grateful to the PubSweet Global think tank for helping me understand this. A consequence of this observation is the need to understand that the developer (as expert) can play a very interesting role in designing the product. The developer essentially keeps the design ‘on the rails’ and within the boundaries of the possible and the doable. This is very important, since CTM is about efficient processes as much as it is about good design and good software.

Cross Functional Collaborative Groups

So, the next iteration will bring the developer (code specialist) and the UX specialist to the beginning of the process with the user. This will be the basis for a cross-disciplinary collaborative group that will design the product together.

User + Developer + UX expert ------------------------> Product

The core players, and some of their challenges, are as follows:

  1. Use Case Specialist – the primary voice in the design process. They must say what they want but listen to the advice or thoughts of the UX and code specialists as to what is possible and doable.
  2. Code Specialist – must play a mentoring role in the design process. Keeping an open mind to approaches they haven’t considered before. One of the big challenges is for the code specialists to accept what the user wants even though they disagree.
  3. UX specialist – they must help make the product look and ‘work’ better than expected by everyone else involved! Care must be taken not to override the users’ requests. This role, like that of the code specialist, is very much a mentoring/guiding role and the UX specialist might very well know where the user is heading with a design but must allow the user to get their at their own pace.
  4. Facilitator – for all this to work, a facilitator must be present at all design meetings. The facilitator is there to moderate human dynamics and ensure everything proceeds on an even keel. The facilitator should not play a role in design.

In previous iterations of the CTM, I played the role of the facilitator and a bit of the ‘code specialist’ (really a technical domain expert). In the next iterations, we disambiguate this. This will also hopefully allow the model to be more easily replicated.

Remote Working

In the current CTM, all design process take place in real space. However, this does not scale. We need to find more effective ways to enable small teams, rather than one big team, to break off chunks of the problem and work together. To do this we will bite the bullet and try working through remote technologies. In this way, our UX specialist (Julien) in France, can attend alongside our code experts (Slovenia, Kenya, UK, Athens), alongside the use case specialists (mostly in California) with me facilitating from where ever I am! In simple terms, we have to make this work.

So we will look to use Jitsi for open source video conferencing, and ahn open source collaborative online whiteboard (there are plenty). Remote participation loses a lot of nuance but I am hopeful we can make this work with a small team if we are disciplined about the process (this is where facilitation kicks in).

Iterations on CTM

So the first step is to try this out. We have started work on a Journal platform so we will try one meeting like this and see how it goes. I think the balance will be something like:

2 x code specialists

1 x UX

4 x use case specialists

1 x facilitator

… probably we start this in June. Then we will reflect on it and tweak the process as we go. I’m not convinced this will reveal the secrets to how to build open source products as a community,  but it is one step further in that direction. I am sure we will design good products this way, but working out how to make CTM scale and how to open it up so it can become a self-replicating community is going to take some time. Still…I feel we are on the right path (and an interesting one!).

Stay tuned!