Project Plan

Introduction

Matrices are basic data stores used throughout evolutionary studies. Large (1000 by 1000), collaboratively built matrices of quantitative/qualitative are becoming increasingly common on the web, and a generic mechanism to browse (interact) with these data in the browser via a "windowing" mechanism would be broadly useful. The interface could be used for any data that can be tablified according to some x/y co-ordinate system that returns the jSON spec, thus making it extremely broadly useful.

The project focuses on building an interface which allow users to browse large data stored in the matrices. With this, user would be able to see and analyse large data stored on the web. It requires to build a jQuery library that will produce a Google-maps-like tile based interface. Users can drag to area of their interest and can see the data more clearly. To improve the performance neighbouring shell should be loaded in the background. Although the original idea is to have the plugin load and visualize large matrices, a well built tool for this task could further be used to display more complex objects (e.g. heat maps, highly detailed images etc.) as these objects can also be treated in form of a matrix. Hence the aim here would be to allow an open format for the cell values (e.g. HTML div) that can be extended to allow any kind of data in the future.

The main features of the tool include a browsable canvas that can be panned and zoomed easily. In the background, the tool would obtain data from the server based on a set of coordinates. These coordinates then need to be mapped to the current zoom level of the data and shown at the correct scale. The approach and implementation is similar to Google maps which sends requests to the server based on coordinates of the map to be loaded.

Technologies

Libraries for development: jQuery, jQuery UI (Draggable can be used for implementation of dragging features for browsing through the matrix). Testing: jQUnit for writing usnit tests. I have already used this before during my previous Google Summer of Code proejct and have some experience in writing tests. I have also written a quick start guide for writing tests using jQUnit.

Caching: jStorage is a library that provides plugins for jQuery to store data locally using Javascript and can be used to cache the surrounding cells. It uses HTML5 and therefore is copmatible with most modern browsers. imageCache.js is a similar library that allows caching of images in the background easily.

Browser Support: The project would potentially use HTML5 features and therefore requires a browser that supports HTML5. Thus it will be delivered to modern, standards-compliant browsers, including:

• Firefox 3.6 and higher
• Safari 4 and higher
• Google Chrome
• Internet Explorer 9+

Similar libraries, potential candidates for help during project:

NOTE: This section is now moved to Research.

• Mapz: Provides draggable image maps. Uses an image overflowing in a div. No caching or dynamic loading.
• Mapbox: Similar to above with more advanced features for browsing maps. No caching or dynamic loading. Sencha touch Maploader: Dynamically loads random points on map while panning and loads the frames dynamically. Might be a good cancidate to look at however, the plugin cant be used directly for the project.
• Canvaszoom plugin: Uses HTML5 canvas to render images of different sizes at different coordinates in order to allow zooming into the images with high resolution. Uses dynamic loading of images at different tiles.

However, there are not many libraries that use dynamic loading for browsing through matrix data. Most of the libraries focus towards providing browsing capabilities for high resolution large images whereas we aim to provide capability to browse through HTML divs and therefore would need to start mostly from scratch. However, there are several libraries that support dragging features which can be reused for the project.

An approach that can be used to pre-fetch data from the server is to identify the direction of zoom and prefetch random coordinates (or zones) in that direction. This is similar to the approach used in Sencha touch Maploader. The main idea here to load random coordinates is to prevent loading too much data which might not be very useful (in case the user changes direction or stops panning at some point or continues panning to a further point). A possible data structure to use here can be a hash table hashed on the values of the coordinates in order to allow easily retrieving the data that has been pre-fetched.

Depending on the layers of the cell data, it might be good to have a separate cell render to display the data. This would also allow the users later to implement their own renders to render the retrieved data in their desired format. the render can be passed the JSON retrieved from the server which would make it easy to adapt later to different JSON formats. For the current project, it would be useful in managing additional layers (e.g. having separate HTML and Javascript for the view).

Timeline

• April 23 - May 21, 2012: Community Bonding period (Study and Prepare myself for the project). Build architecture for the project and decide upon a concrete data providing API. Write a few base test cases for test-driven development.

• May 21 - June 5, 2012: Version 1: Allow simple configuration options for the plugin. Displays the data loaded from the API on a canvas (as per the chosen element during bonding period and first week of implementation). Implement a test Javascript API to return mock data to the component. Implement the first version that loads the data returned from the API and displays on the canvas (The canvas here refers to a generic component that can be used to display the fetched values from the API. Potential candidates for use here are HTML divs, HTML5 canvas, SVG etc.). The first version shows only the text data loaded from the API but should be extensible to allow showing HTML data. Code Review 1

• June 6 - June 20, 2012: Version 2: Version 1 + Event handlers for drag events in the canvas and implement event handlers to display sample data. Implement events for dragging through the matrix and change the coordinates of the matrix as per the drag. This would a event driven module that generates events when the drag begins and ends. These events can then later be caught easily to implement more complex objectives like pre-loading data etc. Code Review 2

• June 21 - July 4, 2012: _Version 3: Version 2 + Caching of data in the background. The main challenge here would be to send as few requests to the server as possible while maximizing the amount of data that has been loaded already when a user visits a cell. _ Implement pre-loading of data in the background based on the direction of drag. Special precautions must be taken to avoid sending too many request to the server for values that are not required to be shown. Some previously shown values can also be cached in order to improve response times. Code Review 3

• July 5 - July 9, 2012: Write test cases for the first half of the project. Prepare documentation and write tutorials on using the current jQuery plugin. Preparations for midterm evaluation.

• July 10 - July 31, 2012: Version 5: Version 4 + extensible renderer component to allow rendering the data in desirable format. The render should be able to handle the data received from the API in order to allow easily changing the format of received JSON at a later point. Implement a separate render component for the data. The renderer should be easily extensible (or replaceable with a completely different renderer) in order to allow users to later use their own renderers for the data. Final Code review.

• August 1 - August 13, 2012: Version 6: Version 5 + Keyboard shortcuts for browsing easily through the matrix. Implement keyboard shortcuts for browsing the matrix. The keyboard shortcuts should allow complete navigation in the matrix using only keyboard. Identify additional tasks to be done (Implement zooming feature to allow users to zoom into the matrix. In case of text based matrices, it is not very difficult. But to able to extend it to image (or HTML), special care has to be taken while scaling the values. Here, the API might also provide finer values based on the zoom level). Prepare a proof of concept for the project. Push the API requests to the server instead of the Javascript API.

• August 14 - August 20, 2012: Test the tool and write up documentation. Implement suggestions from previous code review. Complete any pending job and package any codes, packages or extra files for delivery.

• August 21, 2012 onwards: GSoC scope over. Work goes on outside the scope of GSoC (Discuss how data in a matrix may be "highlighted" in relation to some context defined by a phylogenetic tree).