I found the paper readable and those genetics concepts that I didn’t understand from my one high school biology course were explained well enough for me to follow. I would have liked to see more proof that MizBee is an improvement over other genome visualization software. To be fair, though, I imagine that would have to be conducted by biologists and be measured purely by their subjective preferences.

While I understand one of their methods of using a circular structure for simplifying some of the clutter and providing more information between source and destination, it just doesn’t seem as intuitive as the block view.

The rest of the paper however was also largely descriptive, such as in its explanation of MizBee, and it would have benefitted from further justification for their design choices. On page 3, the authors indicate that their generalized taxonomy is a result of their critique of “the design choices taken in other synteny browsers presented in the literature.” What, in particular, were such critiques? And how does their system differ or compare to these other browsers in terms of its design choices? Why were these decisions made?

Many others have mentioned color use in their comments, and I, too, had a similar initial response to the visualizations. Especially in Fig. 9c, the red and green in the block would fail to provide useful information to a biologist who is red-green colorblind.

I’m curious as to how many people would find this tool useful in their work, as it seems to be very specialized. I would expect it to be small, but biology is a large field, and there were a lot of existing tools, so maybe they were trying to meed a larger demand than is apparent to me.

I’m also interested in the evaluation methods (I saw a conversation had been started about this previously in the comments.) If not many people use this tool, maybe anecdotal evaluation is sufficient for testing MisBee. I am curious, though, as to whether they tested it using a different group of people than the ones they interviewed to determine the 14 important questions that motivated the MizBee’s design.

Although this paper is very specific to genomics which is outside my domain of knowledge, there are however some general rules that are clearly mentioned in the paper which could be useful for any other domain specific software.

1. Characterization of the domain: List down higher level question that the software must answer.

2. Taxonomy of the design space :

3. Non scalability of Colors:

This paper also emphasizes “Edge Bundling” to remove visual clutter that often occurs with large dataset. Although the paper have mentioned use of Spline, but I am sure that real implementation must be difficult.
T
Finally, this paper nicely reinforces the general thinking that no matter how hard the implementors think and design the software, it is the end user that decide how good the visualization software is and their decisions are based on the answers they are looking for from their incomprehensible dataset.

The only concern that I have with this paper and the MizBee software is that it probably does a great job in answering 14 questions, but what if the user slightly change or pose new question. In that sense, how this software is “General” as claimed by the authors.

Overall this paper is very interesting to read and thought provoking.

In the genome view, edge bundling makes us to see minor block connections as figure 5 shows. I like they make the user to choose one source chromosome so that they can avoid the problem from when the user choose all the chromosomes. I am curious how the genome view changes if the ordering of destination chromosome can change.

I like the layering of annotation tracks in the chromosome view. The browser can use any annotation tracks and it seems to be easy to catch meaningful annotation in the chromosome view.

It will be nice if the browser can be expanded to compare more than two species but it may not be straightforward expansion.

On the other hand, I couldn’t really understand from the paper alone what specific algorithms are being used to remove the “noise” and cluster the edges, especially in the second example case. Come to think of it, how much of such details are usually included in visualisation tool introduction papers like this?

In general I feel the weakest point of this paper is the lack of comparison with other systems. For one, they fail to compare other systems in the specific cases of their contributors. It is also not very clear how much more functionality (in terms of the questions answered) MizBee has over other tools. Lastly, there is very few discussion about the use of the tool in the general sense. While I was reasonably convinced that MizBee was useful to the two users that the authors mention, I have no notion to how it would operate in the general case, special against other tools already out there.

I assume that their critique of “other synteny browsers” (p. 3) refers to the browsers they discuss in section 6. The known perceptual principles they base their design on includes the “obvious and effective way” of lines and curves; alternatives are not discussed and no research cited. And if “less than one dozen colors are distinguishable when showing categorical data” (p. 4, though it appears we’ll discuss this more later), then why did they use eight instead of 10? Or 11? The color choice is also questionable since the selection they used from ColorBrewer (8-class qualitative Set1) is not explained. Looking at the tool, this selection appears “print friendly” but neither “colorblind safe” nor “photocopy-able”. Whether RGB and CMYK compatibility alone justifies the color selection is unclear. Similar issues abound in the paper.

The two case studies described do not address the users’ use of or familiarity with other synteny browsers; the second collaborator’s description of using “scatter plots and raw text analysis” (p. 7) suggests that he may have limited experience. Thus the praise assigned to MizBee, though deserved, may also apply to other tools. Making a case for MizBee’s superiority is therefore restricted to a theoretical discussion, and I am unable to evaluate the questions they used as being appropriate for general synteny browsing versus being a union of two distinct use cases with little over lap.

The tool itself looks very attractive; I’d only like to see more justification for its design, as this is one of their stated goals, and to learn more about how it compares to other synteny browsers in actual practice.

Mizbee itself indeed is a very useful tool for genome conversation study. The outstanding performance has already been proved by the authors in the paper and in the case studies. However, the implementation part is too concise for me to discuss further. In my opinion, there might still be some drawback in Mizbee. Firstly, it seems that Mizbee lacks a way to precisely locate the interesting block of base-pairs, for example, a box to enter the number of the base pairs would be desirable. Secondly, another thing which may be worth to integrate is the function to swap the source chromosomes and the destination chromosomes. Thirdly, the capacity and performance,( i.e. what is the maximum size of the data sets that Mizbee can handle? How fast can the view, filtering and zoom operations be performed giving certain hardware?) is not presented in the paper. In the paper, we can see it can obviously handle a size of data set up to 10,000,000.

The next thing I find a little bit hard to understand is how to create the data files for Mizbee. The instructions in Mizbee.org explains the data format, and it seems quite complex. Considering the overwhelming data size in molecular genetics, how can an enduser create such a datafile by his own? A parser might be helpful, but certain parser may also request certain input format, how to maintain a valid interface still seems a issue.

Overall, this paper exhibits a strong focus on the task at hand and thorough explanations of the contributions the author was attempting to make. One thing that did bother me, however, was the sudden inclusion of the related works section. This may just be my opinion, but it did feel as if the authors knew how they intended to structure the paper and simply threw in the analysis of related works in a transitional part of the paper simply because they felt it a necessary element of any research paper.