The Coko community is having a Book Sprint in Cambridge next month. It will be about 10-12 people, and facilitated by BookSprints.net and featuring folks from Hindawi, eLife, EBI and Coko! Community making docs for the community.
We will use Editoria in the process for writing the book, which is a classic case of dog fooding. Looking forward to it!
http://blog.europepmc.org/2018/05/europe-pmc-and-coko-announce-partnership.html
Big news! They came to an onboarding workshop last week in Athens and had a great time!
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…
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…
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.
I used to do lots of events back in the day. The last big one I was really involved in was called net.congestion when I lived in Amsterdam around 2000… it was about the use of streaming media in art and activism. It actually turned about to be a huge, and timely, event.
So… now I’m pondering maybe putting something together around publishing…in the last year or so I have been fascinated by workflow in publishing. It seems to me to be a rich topic and pretty much publishing is all about workflow… if you would like to collaborate to make it happen let me know…its in the ponder stage at the moment…
We’ve tried to build software for other people before, but it wasn’t until we worked with the Coko Foundation that we realised how important a “community-first” approach is. The benefits from the conversations, before any code is even written, is obvious when you start writing and even more obvious when you see the quality of the finished product.
– Paul Shannon, Head of Technology, Elife
Paul Shannon is a great advocate for the way we work in the Coko community. eLife was one of the first to see the potential in the way we work, and I remember clearly sitting in a pub talking to Paul about it with Kristen. He was enthusiastic and genuinely supportive when we explained in straight forward terms that we were trying to establish *real* collaboration and not collaboration in name only which is unfortunately so often the case.
We work closely with Paul and the eLife team, as well as the Hindawi team, and in many cases we are each extending the others team. That is what close collaboration is all about. As Paul states:
I love the pleasant surprise when one of your collaborators solves a problem for you, or when you find a problem you thought was just unique to you being discussed elsewhere. For us, the main benefit is knowing that what we’re building is useful to others and is solving the important problems – things get built more quickly and more correctly which reduces the burden on everyone.
This is very true. In a community when you share the burden of a problem you have the luxury of bringing in a bunch of active minds who have a desire to solve the same thing but are not on your payroll. So, you can leverage expertise in areas that your team doesn’t necessarily have. Software development in publishing these days covers a huge scope – everything from workflow, to file formats, OAuth, to containerised deployments and much more. Its hard for any one team to have that scope of expertise. But we have so far found, even with our relatively small foundational group, that we have always been able to find someone in our community that knows a lot about any given problem space.
So, extending your own team and being able to reach out to others with specific expertise is a huge advantage of working in the Coko community. But it doesn’t stop there. It is often the case that someone will be able to improve on your approach to a specific problem, and sometimes it is also true that someone in the community will offer to build it since they have the same need.
This leads to, as Paul says, things getting built more ‘quickly and correctly’. I absolutely agree, as does Andrew Smeall of Hindawi who also collaborates with us:
[Coko] have marshalled a diverse group of publishers towards a shared goal. Together, we’ve implemented a radically open process of constructive collaboration, where each member benefits from the strengths of the others. The result has been rapid progress towards an elegant, maintainable product.
– Andrew Smeall, Head of Strategic Products, Hindawi
This is awesome stuff. Imagine not having to solve all the problems of building a publishing system by yourself?
Of course there is a cost to this. To communicate this I sometimes use the phrase ‘The cost of collaboration is conversation”. This is very true. In order to benefit from collaboration in an open source project, you have to be communicative. We have several mechanisms to help with this, the mattermost chat channel is one. If you visit the Coko GitLab (where the code is stored) you will also find it is very active with conversations in the commits and the issues (eg https://gitlab.coko.foundation/XSweet/XSweet/issues/106) . We also have a lightweight RFC process (eg https://gitlab.coko.foundation/pubsweet/pubsweet/issues/341), and we also have smaller WorkGroups for developers and designers. These WorkGroups consist of one person per collaborating organisation each meeting and is facilitated by Coko. This keeps the group small and the conversation focused, lowering the overhead for all.
The result of all this is that we can keep the overhead low, and produce better products than if we were working alone. We can also produce them faster, learning from each other as we go. As Andrew also says:
An improvement for one becomes an improvement for all. Individual communities can focus on core areas of expertise — peer review, hosting, discovery — knowing that their innovations will improve the entire system. The result is more creativity, a more diverse set of solutions, and, ultimately, faster progress.
There is a secondary benefit too… communities are in themselves motivating, as Paul Shannon says:
Having other people build components to solve the problems you are facing is a great benefit of a common infrastructure, but also knowing that what you’re building is useful to more than just your team really adds energy and purpose to our teams of developers and designers.
All in all, its hard to argue against this kind of value in collaboration. I’m not currently seeing any downside except (for me) lots of travel! But thats in my DNA now, so I can handle it….would be good though if there was better surf in London and Athens…
We will add more organisations to the mix as we go…some announcements coming shortly. But here too we are being careful. Its important that we add the right orgs, ones that have a willingness to put in as well as take out…we don’t want to host parasites… this ecosystem can only work if there is close communication and a dedication to working together. This requires trust and good faith and if an org enters this tight community with the intention of free riding they will soon find out they are not welcome. For this to work for you, you need also to work for it. It is not a one way street. If you can accept that and get into the right mode, you will benefit greatly AND you will have a great time… communities are also fun when done right and so far our community meets are super fascinating and filled with awesome folks. It is an honor and a joy to hang out with them and solve problems together.
One of the additional benefits, which I touch on above, is learning from each other. In the last community meet, we had a few weeks ago in London each of the three foundational orgs – Coko, eLife, Hindawi – presented where they were with their journal platforms built on top of PubSweet. Each had taken slightly different paths to solve similar problems. There was much overlap of course, but where I learned the most was where someone had tackled the same problem slightly differently…this was really the first time this had occurred in our community and it was tremendously exciting.
As it happens, there seem to be quite a few orgs wanting to jump into the community. So, from here, it is all about scaling gracefully. We will work out processes to manage and maintain this good faith and good will as we grow. The foundations are there, now it’s all about the mechanics of growth…
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…
So, I have a pet thesis…. it goes something like this… Open Source, as we know it out there in the wild, is a code-centric pursuit. Its roots are in code, the culture is all about developers solving problems, the tooling is code-centric, and the culture values code above all else. That is not a very controversial thesis so far. However, I have experienced a lot of kickback when I get to the next bit… and that is, open source has both succeeded and failed because of the these characteristics. It has succeeded to produce a lot of code, and a lot of tools and libraries that developers need, but it has failed in any category of software where the primary beneficiaries of the software are not developers.
To me it makes sense. But bringing it up has produced so much blowback, notably from long-time open source practitioners, that it only reinforces to me the truth in the mini thesis. There is a huge blind spot in open source culture that does not recognise where it has failed. It is a pity because I believe the first step in succeeding in these areas is to recognise why open source has failed. Only then can you fix it.
I believe it will take a long time to change this and I once had aspirations to be part of the fix-it movement, but I think it’s too long a game so I have elected instead to play a part in addressing these issues in realms where I know I can have an immediate effect. Hence, in Coko, a not for profit I co-founded, we are spending a lot of time to see how we can create an open source project that values all contributions as much as traditional open source values code contributions.
Part of this is making way for UX design. It is pretty much the high-value role, when it comes to conquering the most obvious limitations in open source, since it is where the rubber hits the road when it comes to ‘user’ meets software.
In the Coko community, Julian Taquet and Nick Duffield (eLife) are putting a lot of time into this with the able assistance of Yannis Barlas (there has also been a lot of excellent input from Sam and Tam from YLD and others). I’ve shepherded the process from a distance – setting the scene and making the space for the right people to do the right work and making sure this work has the right value accorded to it in the Coko culture.
So, in essence, we have realised that collaboration in UX comes down to three things:
Identifying the common ground actually took some discussion. We initially thought the common ground – think of it as UX space shared across projects – was on the page-level. We thought, for example, one org would need a dashboard and so they make it and others can use it. While this is true for a limited number of specific page level components it soon became obvious that there was a higher opportunity for reuse should we break the page-level components down into smaller components. We then had a short period of lexicon confusions (“duh. what sort of component is a login?”) until we settled on Brad Frost’s atoms and molecules concepts and lexicon.
After that, we could make faster progress as we had identified, and could talk about, a new level of component that had infinitely more opportunities for reuse across projects.
That was the highest level common ground we identified.
Next, we moved onto tooling… there had been a lot of discussion about this. The trick was to get the designers to experiment with and understand the options. It also highlighted the fact that in each collaborating org there was a different workflow that might play into some discussions and not into others. For example, Julian from Coko does as much of the tweaking of CSS variables and values in the code, whereas Nick from eLife does the design and then hands these designs to others to implement. So, in many ways, the questions about tooling are informed by these workflows ;and different people, even if identified as having the same kind of role, have very different questions and needs. This is important to take into account and we will need to keep this very much in focus as we go forward. One easy way to keep issues of this in focus is to always insist that any discussion, workflow change or feature that affects design workflow must include the designers in that conversation. You get better results and people are much happier! Not to mention that it saves a lot of time as there is more informed discussion as you progress and fewer possibilities for major rollbacks because someone wasn’t looped in.
This conversation on tooling took quite a few weeks; there were many options on the table and we wanted to make sure the right people were in the right conversations. It came to a close, for at least the foundational stage, when Nick and Julien met with Yannis in Athens for a 3 day UX meet and nailed down the final agreements on tooling (amongst other things). This highlights to me also the need for periodic in person meets if you can manage it, as required. You can clear out a lot of ‘hanging issues’ in one swoop if you meet in person for short focused bursts.
Below are some pics from this very important meet in Athens showing Nick, Julien, and Yannis at work on the whiteboard in our Athens office.
We now have general agreement on the use of CSS styled components, as well as an understanding of what a basic atom or molecule would look like, a high-level list of agreed design principles, an approach to ‘plain vanilla’ theme with org-specific overrides, and a prescribed set of common CSS variables.
You can see the embryonic documentation about design decisions here – https://gitlab.coko.foundation/pubsweet/design
So, the crew nailed down the tooling with a few things left to discuss. There are many tools in the design/UX workflow. Unfortunately, there are not many good open source tools to support open source design workflows. That is because of the limited scope of open source projects to involve designers as I mentioned above. So design has not been seen as a priority and, consequently, the tooling is not there. You can see this in GitHub and GitLab – where are the tools that support designer workflow?
Which brings me to the final item – process. We are still working this out, but essentially each org will design components as needed, and then scope these to common established CSS variables, and then ask for feedback through Mattermost. When agreed, the component will be built and committed to the common styleguide for reuse. When the flow is established it should be a pretty fast way of working. The idea being, in essence, that atoms and molecules are developed for a target, common, ‘plain vanilla’ theme, and then each org can have their own theme that will use those common components and apply their own CSS values to the common variables.
After writing the above I asked Julien if it all looked ok, he wanted to make the following additional point about tooling and sharing design ideas and mocks:
For now, we’ve stopped the conversation at ‘let’s share svg through syncyng folders and see how it goes’.
The only things that will stay in the library of components, shared for all Pubsweet apps (from Coko and others), is the code. Therefore, since there is no easy way to test mockups with different themes (which is the thing that we would need), we will end up sharing png and discussions (for which, the Increment project could be helpful: https://gitlab.coko.foundation/adam/increment).
So for now, I don’t think we can say more, specifically if we don’t want to force the user on a specific tool.
In other words, the atoms and molecules will go into the shared component library, but the mocks and discussions leading up to the creation of the components will occur elsewhere. This is because the current open source software development tools don’t support these processes (collaboration around iterative design in a live environment). Julien also makes the point that the mocks will also be shared as SVG since that allows each org to decide for themselves which environment (design software) they will use to create the mocks, so SVG, in a way, acts as an interface between the collaborating designers.
It sounds simple, but it takes time to work out simple solutions. We are also finding that there are no established models for collaborating on open source UX that we know of that we can follow… so discovery always comes with an overhead but it’s also exciting to be leading, in some small way, with creating a demonstrable real ‘in the wild’ example of how to collaborate across orgs on UX design in an open source project. That comes with its own challenges, and with its own sense of satisfaction.
Yesterday I presented at MIT Press.
Today, we had a truly amazing day today at MIT Press with the PagedMedia meeting. I’ll post some photos later on today, but in general, it went like this… First we had presentations from some very talented folks that use HTML and CSS to make books – showing how they did it and the results. You might think ‘wow… exciting times’… ha…but for me it was just fantastic. So many good folks and so much to learn from each. Then Julie Blanc and Fred Chasen did two awesome presentations on possible approaches to the problem. Finally we discussed these and agreed on the best path for now, and many people committed to various roles to get this all going…. Amazing…
Anyways…now in the Toronto airport, on my way to BC to do a presentation at INKE, introduced by my buddy John Maxwell…awesome!
