Looking like this
Now | San Francisco |
March 24 | NZ |
April 9 | London |
Apr 11 | Athens |
Apr 16 | London |
Apr 18 | San Francisco |
May 5 | Santa Cruz |
May 16 | Berlin |
May 21 | UK |
Publishing Innovator. Surfer. Ponderer. NZer.
Looking like this
Now | San Francisco |
March 24 | NZ |
April 9 | London |
Apr 11 | Athens |
Apr 16 | London |
Apr 18 | San Francisco |
May 5 | Santa Cruz |
May 16 | Berlin |
May 21 | UK |
Editors are a hard problem. I don’t mean editors-the people… although that might also be true 😉 … I mean the technology you use to write and edit WYSIWHAT?documents. Its tough stuff. Over the years I’ve bet on several of them starting when I first replaced the native wiki-markup editor in TWiki with TinyMCE… and then later CKEditor…and so on with FLOSS Manuals..
The point with editors is that they are like racehorses… you put your money on the best one available at the time. They will win for a while, but no horse lasts forever.
After I abandoned TWiki and we started building Booki, which was later to become Booktype, I brought a bunch of people together in Berlin at an event called WYSIWHAT? to choose the best horse. Which is funny to me, looking back at it, as I had forgotten that over the years I’ve been involved in trying to build community around several different editors.
I had gone into the WYSIWHAT meet thinking it might be the Mercury Editor which was an extremely innovative editor at the time… but the community chose Aloha Editor (see also Kathi Fletcher’s notes from the meeting). So we built that into Booktype. Aloha has since been left behind, although at the time it was the right choice. Funny thing is with these things I still hear people saying “jeez…you chose Aloha, and it wasn’t the best choice”…well… big news… it was the right choice a the time but if you haven’t looked at a clock lately then you might need to be reminded that times change… I wouldn’t pick Aloha today, nor would I pick TinyMCE… you got to go with what is the best choice at the moment.
Then, I chose the Wikipedia Visual Editor for the Tahi/Aperta project. Which was complex, but the right choice at the time.
So, through this history, I have learned some stuff… In my mind, there are several things to consider when choosing an editor, or the underlying libs for building an editor (which is what we are doing now with the Wax editor at Coko). Essentially they come down to:
It goes without saying that I am talking only about Open Source options. And, just to point out the obvious, with closed source options you might do well on (2) above for user (but not API) documentation, but fail on 1 (because you can’t see the code) and 3 (because closed source isn’t about a development community).
Anyways… now we are somewhat down the road with what we are doing at Coko, we know a lot more about community and why it’s important. For that reason, the above would have once been my order of priority a few years ago, but today it looks more like this:
You can go a long way with community support if the tech isn’t quite there – either with help to work out ways to do things in ways you hadn’t considered, or by eventually getting features you need into the core code. In essence, a good community plays a supporting role (as a good community member you should reciprocate) and a good community listens to what it is that you need…
Although docs are very important, and every project should have them, a functioning community can also help a great deal if the docs are lacking.
That’s not to say that the ideal solution doesn’t check all the boxes (community, tech, docs)… just to say that an open source project with community ranks miles above one without. It is going to be more fun and get you where you need to get quicker. Also, and perhaps most importantly, an open source project with community is substantially less risk for you going forward. The more active the community the less chance the project will die if any one individual decides to leave or change direction.
So… back to the races…
Having a good close look at ProseMirror. We already use it in some parts of the Coko Journal systems for editing but are considering it for wider use. It looks pretty great, good documentation and, importantly, a great level of supportive community.
I’m designing a workshop on workflow design for publishing. Below is my first draft. Any comments welcomed! We’ll do one in California in the next weeks and one in London shortly after.
Hanging in Berlin with my NZ buddy Heidi.
PubSweet meet time in London! I think its our third PS event…anyho…a cool bunch of people meeting to present what they are working on. Awesome updates from xpub-collabra, xpub-eLife, and xpub-Hindawi plus PubSweet and the two working groups (Dev WorkGroup, Design WorkGroup)…. one day done, 2 to go! Pics from the first day…
One from Nellie McKesson on her awesome new project Hederis.
https://www.pagedmedia.org/introducing-hederis-and-why-we-care-so-much-about-pagination/
And another from Erich van Rijn about Editoria and pagination.
https://www.pagedmedia.org/editoria-building-a-book-in-a-browser/
Off to London today for the 3rd PubSweet meet. 3 days of joyous banter about all things PubSweet. This meeting will mainly be a work meet with eLife/YLD, Coko, Collabra, and Hindawi/Thin Slices. We are also onboarding some potential new partners.
Then I’ll be on the road to Berlin to talk hosting and have a birthday drink. I’ll also catch up with the Book Sprint folks.
Then its San Francisco for a couple of weeks! Tally Ho!
Article in The Scholarly Kitchen on whats happening in the technology world to support Open Access. We are mentioned a few times:
Jure and Yannis came to NZ for a tech meet. We were lucky Nokome from Stencil.a also came up for a few days 🙂 We did some good work and also saw the sights. Many of the below photos by Jure.