Month: April 2018

XSweet n PagedJS

Two interesting releases coming up that I am involved with. PagedJS is what Fred Chasen and Julie Blanc are working on as part of the PagedMedia project. Its coming close to some interesting releases.

Also, XSweet, the docx -> HTML suite will be released as 1.0 in the first week of may. Look for announcements on the Coko site.

Stay tuned!

Alienated again!

mars_new_years_celebration_201506200007hq

Yep, today – for the third time in a row, the US gov validated my status as an Alien of Extraordinary Ability. Its the actual title of my visa – best visa title ever. I didn’t even have to show them my spangly green head antennae. The visa is also known as the O1. Another 3 years I can work in the US 🙂

Image by NASA/Bill Ingalls [Public domain], via Wikimedia Commons

Editoria Webinar

Editoria is the book production platform we have been working on with the University of California Press and the Californian Digital Library. If you’d like to know more there is a webinar coming up (May 15) led by Editoria Community Manager Alison McGonagle-O’Connell.

Sign up for the webinar here: https://ucpress.zoom.us/webinar/register/WN_6UmmLJI2RviMh-hXcJTq_Q

OLPC

img_3558

So, you may never have heard of OLPC, but it was quite a thing. OLPC = One Laptop per Child. A project initiated by MIT. Its mission was to change the world – essentially to educate millions of kids that did not have much in the way of educational resources. The basic idea was to make really really cheap laptops and then get them to kids that needed them. The Laptop was pretty innovative at the time as there was no such thing as a ‘small factor’ laptop back then. You just had big, expensive, laptops. OLPC tried to get the price down by innovating in form factor and the attendant technologies like screens…

olpc-x0-unboxed

It was a pretty cool thing.

Anyways… there was an interesting article that a friend passed to me about it. I just landed in NZ, so I’m pretty knackered and can’t quite write what I want to write about this now. But here is the link:

https://www.theverge.com/2018/4/16/17233946/olpcs-100-laptop-education-where-is-it-now

I’m writing about it here as I was pretty close to the project. In fact, I facilitated all the documentation and worked closely with Walter Bender and the crew. We (FLOSS Manuals) did a few Book Sprints to create the docs and as it happens I found this old, old vid online from that time:

I found the OLPC project deeply flawed. It was a movement without proper resourcing and an untethered ambitious aim. But I liked Walter and many of the people involved. It was interesting to watch this whole thing unpack slowly infront of me. Anyways… will read the article more thoroughly when I’m more present and make some more comments from my own experience of the project.

continued…. actually, I slurped up a coffee and read the article more closely. It’s pretty accurate. I realised things were topsy with the OLPC when I discovered the reason why we were doing docs (apart from them not having any in the first place) was because the laptops were selling at (something like) $180 a unit, but costing $186 (0r something) per unit in support costs alone. They were making a loss on each machine purely on support costs. It wasn’t a surprise to me as many people needed a manual just to work out how to open it up…

1 2

 

 

But I have to say, Walter Bender was the real deal. Super smart and humble as pie. He had his heart and vision in the right place, and if he had been supported the OLPC project would not have lived and died as a hardware project. His vision was much greater and worthy but, as the article discussed, didn’t get the traction over the sexy hardware sell.

Anyway… some of the manuals we made are still online 🙂

http://booki.flossmanuals.net/xo/

It was even translated to Farsi and a heap of other languages that are only to be found now in the Internet Archive (eg Greek, Arabic and others). The docs were also available in book form, electronic book, and on the laptops themselves.

117 one-laptop-per-child-nicolas-negroponte-9 software_activities_11 2952057847_42de996872_b img_3342

Libero Meet

We had a good meet at the eLife offices today (Cambridge, UK). We discussed all things Libero, which is a eLife led initiative to provide open source content delivery systems for journals. I learned a lot about what they have been imagining and building. It was a super meet. Lots of smart folks from Hindawi and eLife which is going to lead to an awesome combined effort.

Very honored Paul Shannon asked me to facilitate it 🙂

dsc05400

dsc05387 dsc05388 dsc05389 dsc05390 dsc05396

Its all about workflow…

In the last 2 years, I have been very privileged to see inside the workflows of many publishers (book, journal, micropubs), aggregators, and preprint servers.

As a system designer, or one that facilitates others to design their own systems, this provides incredible insights into common struggles all of these organisations have. Recently this has given me pause to think about the system design process. So below is a little emergent theory of the importance of mental models in the process of workflow design….

  1. Who better to ask about an organisation’s workflow than the publishing staff themselves?
    There isn’t anyone better! Publishing staff are experts in what they do and they know every nook cranny of their workflow. They know the broken parts *intimately* since they live the pain on a day to day basis. They also know what works and what cannot be sacrificed.
  2. Publishing staff are the best placed to know how to improve their workflow (if given the chance)
    In order to be able to improve a workflow you need to first know it intimately. As above, there is no one better to do that than the publishing staff themselves. If you want to solve the problems, publishing staff need to be at the core of the design of solutions. By publishing staff I mean the actual people doing the publishing work.
  3. Publishing staff don’t design their own solutions
    This may seem like an oxymoron, but hear me out. In order to design an improved workflow you need a *perfect* mental model of the current workflow and what needs to be done. You need the first so you make sure you aren’t missing anything, you need the later so you know exactly what you can miss (what can be left out, what needs to stay)… Often I have seen one person given this job, and that person comes in from outside the org, or they are from within the organisation but have never done the publishing work directly. That leads to an imperfect mental model and pure speculative theory as to where and how the flow can be improved. It simply doesn’t work but it is the way it is done everywhere.

So… the heart of what I am trying to get at here are these three questions that lead on from the above which I am currently asking myself – why it is we don’t involve the publishing staff intimately in the design of better workflows? What is this mental model stuff and why is it so important? Why do I have this growing gut feeling that it’s all about workflow?

So… as a first, rather rough and quick response to myself on the above three issues…

  1. why it is we don’t involve the publishing staff intimately in the design of better workflows?
    Ok… I might actually sound rather nutty when I say this out loud. I believe the problem lies in the history of software development… First of all, these days we conflate workflow with software. They are not the same thing, but we make the mistake of equating the solution to workflow as software. This is far from the truth… but it is what it is…so, this is where the problem starts. To compound the problem, I’m going to go out on a limb and say that I think software dev today, including ‘Agile’ and Lean etc… repeat the same mistakes as older methodologies like, for example, ‘Waterfall’ and Xtreme Programming etc… That mistake is simple – the solutions providers are outsiders to the problem. I have at times, to be sure, been that person in the past. So I’m not pointing any sticks here…well at least, if I am its also at a past me. Waterfall treated the ‘users’ as research objects. That will only give you an outsider’s solution. Agile (etc) make me a little crazy because they try and cross that divide with tricks like ’empathy maps’ and creating avatars (which is, literally, a process of drawing pictures of the ‘users’ and guessing what they want). It’s no good. Why use avatars when you can actually just ask a real, living, experienced, member of the publishing staff? I have a lot more to say on this…but I’ll leave it here for now, suffice to say these problems situate the ‘end user’ at the end of the process ie. when the software is designed and / or delivered.
  2. What is this mental model stuff and why is it so important?
    This is a new insight for me. In a former life, I was a Book Sprint facilitator, and I own Book Sprints Ltd (though I have little to do with the operations). Recently the staff there have been pondering how to communicate the value of Book Sprints and interviewing people that love the process. One such interviewee hit so many deep points I was astounded (I’ll ask if I can share her name and credit her here). Her core point was this – Book Sprints, as a highly immersive collaborative model for book production where the experts (usually programmers) write the book together  — [in this paarticular case we are talking about corporate documentation of highly complex software systems], gets to a shared mental model of the complex system exceedingly fast – less than 2-3 days. This is shared as a book so others can ‘get inside’ that mental model. If the same company hires an experienced tech writer to do the same thing, they will take at least 6 – 8 months to arrive at the same level of understanding. It will take them that long to develop the same mental model of the system. That’s the point. (Also, the collaborative effort will simply pull in more nuance, at a deeper level of understanding, that the lone contractor can, arguably, ever do).That is quite an insight, and when I heard it, I recognised the truth in it right away. The same is true for our workflow design processes. If you want the best workflow design you first need a perfect mental model of the problem. It is critical. So, get the staff involved, and if you want to save money and get the quickest design process possible, get them involved early.
  3. Why do I have this growing gut feeling that it’s all about workflow?
    Well… because publishing is not about technology, nor is it about formats, nor is it about a confused lexicon that we all think is stable (how many different types of Editor roles are there? what do you mean by peer review?). Publishing is about none of this. It is about how you get a document, how you improve it, and how you get it to others. That’s it. And that is all about workflow…