Blog
Coko & eLife partner on first PubSweet fueled journals submission & peer-review platform
Seeding a New Ecosystem: open infrastructure
Take Editoria for a spin
Making decisions in a small team and keeping it fun
A look at the future of journals with xpub
Editoria 1.1: Meet the Automagic Book Builder
A sneak peak at what’s next for PubSweet
Travel the long and winding road to PubSweet
Ink 1.0 is here!
Baby steps to user-centric open source development
Why we’re all in open source now
Getting Started with Coko
Editoria 1.0 preview
Preprints won’t just publish themselves: Why we need centralized services for preprints
INK – the file conversion engine
How we’re building the ‘mountain chalet’ of complex conversions
Sowing the seeds for change in scholarly publishing
Open Source Alliance for Open Science
Editoria Newsletter Out Now!
INK client upgrade
All About INK (explained with cake)
Track Changes (Request for Comments)
Book on Open Source Product Development Method Released!
Italics, Buenos Aires and Coko?
Editoria Update
Where we are with File Conversion
A Typescript for the Web
Coko Celebrates Year One
Editoria – Scholarly Monograph Platform
Adam Hyde’s Blog
Introducing Christos
Introducing Yannis
New PubSweet release
Attribution in Open Source Projects
Open Source for Open Access
Reimagining Preprints: a new generation of early sharing
Introducing Stencila and Nokome Bentley
Reimagining Publishing
Introducing Charlie
PubSweet 1.0 “Science Blogger” alpha 2
PubSweet 1.0 “Science Blogger” alpha, INK 1.0 alpha RELEASES!!!
Collaborative Product Development
Publishing for reproducibility: collaborative input and networked output
Substance Consortium
UCP & CDL Announcement
Release 0.2.0 is here!
CKF receives funding from the Gordon and Betty Moore Foundation to transform research communication
Technology Slows Down Science
[tech post] CSS and Drop Caps
Vote for the pubsweet logo!
Introducing Substance
Digging Collaboration and Cooperation: Code for a New Era
Coko 2015
PubSweet 0.1 Release
Coko Resources
Making science writing smarter
What I Have Learned About Building Community
Introducing the Tech Team
Knowledge and Communication
PKP and CKF Strategic Alliance
CKF Launches
April 18, 2016

Release 0.2.0 is here!

Post by Jure Triglav

0.2 release announcement. Download sources from here: https://gitlab.coko.foundation/pubsweet/core/tags/0.2.0.

Four months and 168 commits later, the 0.2.0 release of PubSweet is finally upon us, and it’s packing a punch! (For the uninitiated, PubSweet is an open source framework for building knowledge production systems from reusable components.) There’s a number of key new features I wanted to show you: setup script & configuration, themes, user accounts & roles, and adaptive UI. Walk with me.


Setup script & configuration

In PubSweet 0.1 we had a pretty funky command line installation process, but this release comes with a lovely setup script that makes it easier to set up a new instance of PubSweet (for more information take a look at the README). The script asks you some basic configuration questions and looks something like this:

Setup script

Sure, it’s a bit on the colorful side, but I find it helps to have a bit of color when you’re debugging, it’s 3 AM and you’re running it for the 100th time.

We’ve also introduced a way for developers to configure the application by editing config.js directly. This, for example, is how you configure the editor and reader components, and set the theme in config.js:


  module.exports = {
    editor: '../registry/Substance/Writer.jsx',
    reader: '../registry/Substance/Reader.jsx',
    theme: 'default'
  }

As the framework and its components mature, the command line setup script will be replaced by a GUI based setup, where users will be able to pick and choose components that suit their needs so you can configure PubSweet as a book production tool, a tool for producing and evaluating scholarly manuscripts, or a journal platform, internal office suite and plenty more. If you use the GUI-based setup then the choices will be recorded in config.js, which is the single source of truth for configuration.

And as you have probably noticed, one of the things you can configure in config.js is:


Themes!

For all you designers out there, now when you import styles for a component import styles from '../scss/BlogpostList.scss', we’ll first try to find the themed version, e.g. BlogpostList-dark.scss if config.js sets theme: 'dark', and automatically fall back to the default stylesheet, if the file is not found. This way you can incrementally style your app and easily switch between themes with a single line change.

Dark and default theme

It’s painfully obvious we have not been focusing on the beauty of the interface just yet, but themes will allow us to do this much more efficiently. (Psst! We have some UX talent helping us…more about this soon!)


The big one: authentication and authorization

The biggest new concept we introduced in this version is user accounts. 0.1 had no authentication as we just wanted to get it out the door as soon as possible. Of course, no journal software or book production system (for example) is very useful without authentication so with 0.2 are now able to sign up & login with your details.

Signup

This has all the expected bells and whistles, such as error messages when a username already exists, your password is not correct and/or other unfortunate cases.

In technical terms, our backend API is issuing tokens (JSON Web Tokens) when it finds a match for a submitted username and password combination. This token is then stored in the browser and reused with every API request. The API then reads the submitted token and authenticates the user based on it. Or in other words: at this point the API knows who you are.

The implementation is far from complete but we wanted to build this from the ground up because component based systems think differently about authentication and we needed to start off on the right path. Things like password reset email and user profile editing are still missing but we’ll get their pretty quick now the ground work has been done.

Roles

With the introduction of user accounts, we are also introducing roles. Roles are extremely important in this space and helpfully almost every publisher out there has its own idea of what a editor, author, reviewer etc. is and what they can do. We kept it simple for now, but again we have put down a good foundation to anticipate very fluid role definitions. In this initial implementation, a user can be either an admin (can do all the things), a contributor (can create posts and edit them) or a reader (the public, can read only published posts).

Users and roles

Admins are the only ones who can manage roles in this first iteration, and the current roles are quite simple, but we’re using a concept flexible enough to adapt to very complex roles-based systems (Access Control List, node_acl).

Adaptive UI

And as always with users and multiple roles, there must exist some concept of the current role and role switching. For example, in the real world a researcher might be both an author and a reviewer for the same publisher. Therefore, there must exist a way for me to say I’m now playing the role of a reviewer, and now I’m playing the role of an author. Right? Turns out that while this approach sounds good in theory, people find it incredibly tedious to constantly switch roles in practice. Thus we decided to try and deal with this a bit differently, i.e. by showing or hiding elements based on the user’s roles and action that the elements represent. I think it’s better if I just show what I mean (left is what an admin, user newton, sees, right is what a contributor, user maxwell, sees):

Adaptive UI

So there is no need to switch in and out as different roles if a user has multiple roles, PubSweet will automagically take care of things and display everything in the right place for you and manage rights and permissions seamlessly.

Let’s dig a quite a bit deeper for just a second and let’s take at a look at the edit button specifically:

{ AuthHelper.showForUser(auth, blogpost, 'edit') &&
  <LinkContainer to={`/manage/editor/${blogpost._id}`}>
    <Button bsStyle='primary' className={styles['button']} title='Edit' aria-label='Edit'>
      <i className='fa fa-pencil'></i>
    </Button>
  </LinkContainer>
}

What the above code does is ask the AuthHelper if the current user can perform the edit action on this particular blogpost, and the AuthHelper then evaluates all of the user’s roles and determines whether the user can edit (returns true) or not (returns false). This return value then guides our UI to show (and hide) the correct things.

We’re still evaluating if this is the best approach for a multi-role UI, and we’ll keep an eye on it as the number of distinct roles and actions that need to be managed grow.


Looking forward and wrapping it up

A great deal of new features & fixes have been added in this release, and yes, that’s really awesome (do let us know if it’s not) – But it doesn’t end there, as we’re already hard at work on release 0.3, on big features like real-time collaborative editing. If you’ve read this far, we already love you, and I’d like to invite you to be a part of our community! If you would like to discuss PubSweets features and direction, contribute code, help make it pretty, or stand on the sidelines and cheer, then jump into the Coko chatroom

And that concludes this episode of “What’s New In PubSweet?” Have a good one!