Collaboration on UX

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
  • tooling
  • process

Common Ground

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.

Tools

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.

image-1

file

image-2

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?

Process

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.

Coko Bot

Tam, an outstanding chap and great person to have involved with the Coko community, built a nice bot for our Coko online chat (we use Mattermost). Anyone can tag a comment in mattermost with :cokobot (a shortcut for the cokobot icon) and that comment will be included in a weekly newsletter emailed out to the subscriber list. To subscribe you just need to jump into the Coko chat and type ‘@newsbot subscribe’. It’s pretty cool and a very lightweight way to keep everyone notified of significant developments.

Here is this week’s newsletter FYI, usually they are longer than this… I think we had a lazy week 😉  (#weekly is our tag for an individual’s weekly update):

End to end tests for starter are passing with postgres ?
from tamlyn in pubsweet on Fri 26th Jan

OSCON is coming up, perhaps we should work out where a coko-community application might fall? https://conferences.oreilly.com/oscon/oscon-or :cokobot:
from adam in town-square on Sun 28th Jan

Coko just joined the W3C 🙂
from adam in town-square on Tue 30th Jan

#weekly meetings, meetings. meetings. Catching up with Paul S, and also the Hindawi folks (about design process). Meetings with Yannis before he left for holidays so I can support the Athens team over the next 2 weeks. Strategic planning with Kristen and Carly. Planning PubSweet meet in London.
from adam in weekly on Tue 30th Jan

#weekly Previous week I’ve finished the implementation of polling regarding the fragment’s lock. Also, Christos and I, fixed some issues regarding the Vivliostyle, a bug in note callouts of Wax Editor and a bug we’ve discovered in the mechanism of releasing lock for fragments. Finally, I’ve deployed the new version of Editoria and the testing has began for UCP. This week I will start with further refactoring of the Editoria Bookbuilder and I will continue doing that until the project will be in alignment with the PubSweet universe.
from alexgeo in weekly on Tue 30th Jan

#weekly Last week, I worked mostly with the xpub issues. Some small ui changes that Dan suggested, and started fixing bugs that are too obvious in order to start testing it. I Also deployed xpub to xpub.coko.foundation. I need to check it today to be ready.
from john.kopanas in weekly on Tue 30th Jan

#weekly Last week upgraded React in the monorepo, and used Jest to test everything globally (vs lerna test that runs yarn test in each project). Found out some tests weren’t being run with CI so I fixed that. Now I’m testing React 16 with our current apps, before merging and releasing the upgrades. (Happy to see that the polling/locking solution is working with Editoria and using both a client and a server component! Good job folks!)
from jure in weekly on Tue 30th Jan

#weekly last week: graphql server and postgres conversion. This week: continuing with postgres especially where it concerns interaction with the CLI.
from tamlyn in weekly on Tue 30th Jan

#weekly refactoring kube templates, wrestling with aws bug and let’s encrypt rate limiting
from g-sam in weekly on Tue 30th Jan

Commits

One interesting metric for the health of an open source community is the number of commits – how many, and how many orgs/individuals represented. Below is a screenshot of activity on Coko’s gitlab  repository (https://gitlab.coko.foundation). It shows the activity over one day. Looks pretty good! Note – this is just activity for developers…  it’s not a good metric for activity of other members of the community, especially for designers… I’ll post a bit of an update about our design activity in a bit as it’s pretty interesting what’s going on….

One days commits. Showing a healthy early stage in an Open Source project.

 

Coko looking for a Editoria Community Manager

If you know anyone that would make a great community manager for Editoria then let me know!

Coko in partnership with UC Press and the California Digital Library are hiring a Community Manager to assist with adoption of the new Editoria platform for book production.

The Community Manager will manage the publisher, developer, and service provider communities for Editoria—a web-based, open source book production software built on the Collaborative Knowledge Foundation (Coko) PubSweet framework for the University of California Press and the California Digital Library. Using proactive marketing and outreach strategies and activities, the community manager will drive adoption and further enhancement of the Editoria software and play a key role in the evolution of Editoria’s sustainability. The Community Manager will be responsible for managing all public-facing work related to Editoria, including communications, PR, social media engagement, website content creation, and business development.

The position is funded for one year with potential for longer term depending on funding and performance. Ideally the candidate would be based in the Bay Area, however remote candidates will also be considered. Salary commensurate with experience.

The full job description is available here (PDF). Email us at team@coko.foundation with questions. Please share with potential interested parties!

 

 

Coko is looking for Node.js/ React devs

Newsbot

Tamlyn Rhodes from YLD in London has developed a cool robot for our instance of Mattermost. It is a newsbot. Essentially, anyone in the Coko Townsquare channel can message ‘@newsbot subscribe’ and will be subscribed to the Coko community newsletter.

The newsletter is an automatically prepared email, compiled once a week. The robot looks through all posts that start ‘#weekly’ (we use this for weekly updates) or ‘:cokobot:’ (tags with a cokorobot icon) and adds these items to the weekly image newsletter (bot icon by Julien Taquet)….we are trying it out this week! Cool stuff. You can see Tamlyn in the pic below, center stage in orange. Photo taken last week at the London PubSweet meet.

dsc04103

The Perpetual Nomad

I’m on the last stint of a 2 month mission-driven trip, taking my Shuttleworth Fellowship/Coko mission to the world. By the time it is concluded, (the last leg is Singapore which I leave for in a few hours), it will have included 3 continents, 5 conferences, funder meetings, partner meetings, the onsite facilitation of 2 publishing workflow products, some workflow consultancy, and the facilitation of a 3 day PubSweet meeting. Also, a large number of meetings, both remotely and onsite. This isn’t the first trip like this I have made this year. I asked Yannis and Jure from Coko how many months they think I traveled in total this year as they know all my movements. I thought it was around 5 months, but they both thought it was much more, perhaps 6-7. I dunno, can’t really be bothered working it out but that sounds about right.

It has been great, but also it is hard to do this without a cost. While work benefits, there is a personal cost – essentially you give up any idea of a normal life, and also you can expect a health cost. Traveling is hard on the body. You eat at odd times due to the constantly changing time zones, it isn’t always easy to eat well, you experience erratic sleeping patterns, the on-demand nature of socialising can wear you down, plus you can pretty much forget exercise (not to mention the cumulative total of 5 or 6 days that I have spent sitting still on planes this trip).

I have tried to work some exercise into this routine – namely surfing. I love it. Also, it’s one of the best ways to meet ‘normal people’ – people not connected to what I do. Sitting out the back of the wave you meet everyone from theology students to t-shirt designers to Department of Conservation workers. You don’t meet too many assholes 🙂 It is a nice way to just be a human amongst humans. Surfing is a really interesting sport. Out on the waves, you are just another surfer, enjoying surfing and nature together. Its good for the ego to be the clumsy schmuck who can barely stand on a 2ft wave! Surfing is pretty awesome. But it is not the most practical of sports! Also, it doesn’t always work out when planned – I stopped for a few days in Portugal to work and surf, and fell sick… This is often the case, that when you stop in the middle of a travel stint, your body gives up all defenses and you get sick. Over 2 months, I got about 6 or 7 surfs in, not nearly what I had imagined when I started out. So, I’ll have to look for something else to play that role.

Also, although I had time with friends and seeing some awesome people, when I look back, it is hard to see it as anything other than 2 months straight working. Seeing friends was squeezed into brief moments ‘in between’ when I could grab them. I also try to schedule in breaks now in long trips, but they don’t always pan out, I’ll keep doing it though as when they do work they can really help to refresh.

I’m not complaining! Just important to reflect upon this for myself.  I have thought I want to get more of a balance on my life and spend more time in some sort of ‘normality,’ but actually, when I look at next year’s calendar and muse on what’s going on, I count around a possible 15-20 Coko events excluding any conferences etc that we would be invited to. That’s at least 4 PubSweet community meets, plus a Coko team meet, plus some potential Editoria-specific community events, OS Bazaar events like the one we just did in Berlin, Open Source Alliance for Open Scholarship (Superfriends), and a large Coko publishing conf, PagedMedia meetings, plus I want to spend some 1-to-1 time with the crew in Athens and Slovenia and everywhere. On top of that, there are some things I really want to do such as visiting some of the Shuttleworth fellow Fellows for some potential collaborations which are looking pretty interesting. My first trip next year is Jan 10 (to keynote at a conf in Canada), it’s an early start and I don’t see me spending much of the two months after than in any one place. I mean… I ain’t complaining – it is my choice to do these things and I do it for a reason, I like to see the mission progress, and I like being in the middle of it all –  but also I actually don’t know how sustainable this pace is going to be anymore. Especially when I actually want more of a work-life balance. Tricky when your life has been your work/mission for 20 years (first as an artist, then open source, now open source/open access/open science) and you feel it is time to change gears. I mean, I know how to travel, and I have always held the position that you have to do whatever is necessary to further the mission, but as I get older (49 now) the toll of this kind of lifestyle is heavier.  So, I guess I’m going to have to do some thinking…

Anyho.. just pondering…I’m off to the airport now to fly to London (from Athens) so that I can fly to Singapore for a final conference. Then San Francisco on Thursday, a few days later I’ll be in NZ….tally ho!