Major Compulsory Revisions

A well written article describing mason, a web widget to display features on a biological sequence. I consider the creation of atomic components for the web to be a valid contribution for bioinformatics and mason goes in the right direction with this goal. However my concern with this paper is the low level of innovation of the tool. Feature viewers have been around for several years, and although the authors state the difference with some existing tools, the novelty of the component is still non significant in my opinion. The major difference with well established tools(i.e. Genome and protein viewers) is that mason is conceived as a widget and therefore modular enough to be embedded in a website; because of this, the authors limit further comparison to 2 published widgets: FeatureViewer and pViz. The authors claimed that FeatureViewer has a complex setup(Line 64), which I agree with, however the improvement that mason offers is not clear. The simplest example in both cases requires using their own data model and uses by-default values in all the configurations, but mason still requires the definition of the callback object; in more elaborate examples both require the user to do a mapping between the source and the in-house model, but the creator files for mason are actually more complex. This might be about the particularities of the example, if thats the case I would recommend creating a step-by-step tutorial on how to use mason to add your own features to clarify what is really needed to use this widget. The advantages/innovations of mason over pViz are also unclear. The authors say regarding pViz: “no native support for true, data-driven coloring…” (Line 71). However on the pViz webpage i found an example that not only uses different colors depending in the annotations, but it is possible to use other shapes: http://research-pub.gene.com/pviz/examples/example-custom-display.html One advantage described in the paper between these two alternatives is the optimization for many overlapping annotations. If I understand correctly the real difference is that mason includes a collapsible option for such cases, while the others display them in other tracks. I think this is a nice feature. The other new feature in mason is the row-level summary bars, which I really like. However I think none of those two features are really game changers and I doubt a developer would choose to use one widget or other because of the inclusion (or not) of these features.

The lack of zooming/panning capabilities limits the widget to very short sequences, the longest sequence in the example has 324 bases and it stills works well, but when longer sequences are used the developer using this widget is going to have to choose between getting something really crowded where features won’t be distinguishable, or including the graphic on a very long SVG element, and only being able to move around by using the scrolls of the browser, which goes against any responsive design principle.

Mason has been described using a model of callback functions to manipulate the behaviour of the widget depending on the data provided (Line 97). I think it is a good strategy, but I would recommend having a by-default set of callbacks in case the user wants to use mason in the most basic way. I tried using null and an empty object in one of the existing examples but that breaks the code, so if is there any way to achieve this, it should be more obvious.

On line 134 the authors mentioned that mason allows including separate sources in the viewer. The only example where two different sources are displayed with mason requires 2 instances of the viewer, they communicate with each other nicely (kudos for that), but this is different from getting info from different sources. The only way I can see mason being able to do that is to generate a combined JSON data model, but if thats the case I wouldn’t count that as a feature of the widget, because it would be part of the pre-processing of the data by the developer using mason.

In the conclusion section there is a sentence saying that “some familiarity with JavaScript is required” (line 213), I think that to be able to use mason in any scenario out of the scope of the examples, a good understanding of javascript is needed. For instance, to do good use of callbacks the developer needs to understand how the JavaScript event loop works.

Minor Essential Revisions

The complementary information about the paper has been hosted at github, taking this into account I would recommend using github pages to host the documentation as or at least as .md files, because having it as plain .txt files makes it inconvenient to browse and search. In my opinion the reference documentation should follow a javadoc style, which can be generated in javascript by tools such JsDoc, YUIdoc, etc.

Discretionary Revisions

The inclusion of the source code in a collaborative repository as github gives it a level of visibility, however I think there are quite a few additional repositories that can help mason to be found by potential users, there are general repositories for packages in javascript such as npm and bower. And there are efforts in the bioinformatics field to have registry of the components related to the field. e.g. BioJS and bionode.

Besides the examples it would be nice to see use cases where mason is used. e.g. blogs, websites, etc.