New features in Healthvis v1.2

We’re rolling out version 1.2 of our package, which includes a new visualization (described in an upcoming post) as well as some changes to package functionality described below. You can find instructions for updating your package on the install page.

Passing Data

In the past, if a user called a healthvis function it would pass the user’s data to the server where the visualization is rendered. We did this so that users could save their image to the server for the purposes of sharing and embedding. There were concerns about the passing of private data to the server, and some would prefer to visualize their data without sending the data away from their local machine.

We have changed the basic architecture of our package to address these concerns. In v1.2, the visualization is rendered locally by default. User data is only passed to the server if the “Save to Healthvis” button is pressed, at which point options for permalinking and embedding will become available. The visualization still appears in a web browser, but data do not go to our app engine server until the button is pressed.

To accomplish this, we have moved to using web sockets. As with other R utilities that use web sockets to pass data, your R environment will be suspended after you call a function until you stop the process.


We have had some issues with embedding figures, since figures with static heights and widths would not resize in a smaller embedded window. Viewers would have to scroll around the originally-sized image in the embedded iframe, and would not be able to see the entire visualization at once. To address this issue, we have added a function called healthvis.getDimensions() to the javascript side which checks if the figure is embedded and resets the height and width of the figure accordingly. Now viewers will see the entire image, resized to fit within the frame on the page where the figure is embedded. We are still working out some kinks with this (e.g. issues with different browsers), so please let us know how this feature is working for you.


We have reorganized our github repository according to this strategy. Basically, we will maintain a master branch from which users will install the stable version of the package. Parallel to this branch, we will have a develop branch and feature branches for in-progress development. These will be merged after adequate testing is completed.

The upshot for developers is that you can now make a pull request on the develop branch, (hopefully) making the development process more streamlined. As always, you can read about development here.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s