---
tags: biojs
---

# BioJS 3.0 Draft spec

## Goal

There are a few main drivers behind drafing BioJS 3.0:

1. **What:** Enhancing and incentivising the quality of tools shown on the registry. **Why?** Currently, many of the tools are low-quality - i.e. they are not able to build, are outdated, or are lacking in documentation.
2. **What:** Allowing visualisation previews within the registry. **Why?** Currently this is a technically challenging task, which could be made easier with a clearer spec.
3. **What:** Enhance usability of components for end users by creating two-line component embeds (one line to include the script, one line to initialise the tool). **Why?** Whilst the 2.0 spec was appropriate and congruent with relevant design paradigms at the time, browser and web technology moves fast. Webcomponents are now well supported and simpler for an end-user to implement.
4. **What:** Enable offline compatability for BioJS tools. **Why?** This will increase access for areas without robust internet connections. Certain bioinformatics initiatives, such as Galaxy, prefer tools that can be used wholly offline, so long as the data the tool wil use are available in a local file. Specifying if a tool can work with local data will allow conscientious developers to easily find offline-ready tools.

## Users

We have two types of target user:

1. **The naive user**: Someone who can comfortably follow instructions to copy and paste code. They probably don't want to learn how to compile a node package, nor do they wish to take the time to do so. They're interested in BioJS as an easy way to get a data visualisation on their webpage, a figure for their paper, or a quick copy-and-paste tool for their application.
- 1-2 lines of copy paste is all they should have to do
- visualisations are important: they want to preview the app they'll be using
- Quickstart docs are their best friend.
- Doesn't much care about licencing, so long as they can use it.
3. **The software developer**: Someone who doesn't mind following a set of instructions in order to compile from source, and prefers the option of tweaking the code if needed. They may extend a tool, require it as a dependency for their tools, or expect advance usage options.
- Wants developer docs - clear build info,
- all dependencies are downloadable and re-usable
- ideally with a permissive licence that allows re-use in any way. (i.e. GPL may be too prescriptive)

## Tool specs

### `package.json`:

{
   "sniper" : {
       "first" : "images" // the default visualization to be displayed when more than one exist
   },
   "buildJS" : "http://www.some.absolute.url/please",
   "buildCSS" : "http://www.some.absolute.url/please",
   "previewImage" : "http://www.some.absolute.url/please/preview.png"
   "tags" : ["biojs", "biojs3", "biojs-offline"]
}

`sniper` - TBD
`buildJS` and `buildCSS` - a link to a single built HTML and/or CSS file. These properties are important in order to ensure naive users can copy and paste without requiring them to build a script.
`previewImage` - (optional) enable a single static preview in the registry. Absolute URL to an image file. *(Should we recommend a size or aspect ratio?)*

## Things to think about

- Events management system - afaik this was not broadly used (can anyone dispute or confirm this?) https://training.biojs.net/details/events/ and maybe should be ported like-for-like with webcomponent relevant considerations taken into account.
- [Metadata](https://citation-file-format.github.io/) - I'd like to recommend (but not require) that tools include a citation.cff file.