GSoC Week 7: Production Prepping

This post is part of my Google Summer of Code (GSoC) series to develop a "Pathway Presenter" for WikiPathways. You can find other posts in the series here.

This week has been a hectic one - I have moved back to the UK, so trying to fit that around this project was difficult. I am extremely happy to say that I graduated Cum Laude with best thesis from the Maastricht Science Programme. The day after my ceremony (and plentiful partying), I loaded up my parents' car with all of my stuff and we began the journey back to the wonderful land of proper tea. By Monday, I started working on this project again. However, I have worked on it less than I would have liked to but I've had some productive hours of work so have got everything I wanted to do this week done.

Graduated! Not the nicest picture of me, I must admit, and my hair is truly too long. But I got a huge bunch of flowers.

Preparing Pvjs for Production

I have spent very little time this week directly working on Pathway Presenter (only bug fixes). Instead, I've spent some time getting Pvjs ready for production on WikiPathways. Anders (lead dev of Pvjs) has spent some time fixing regression errors for the actual diagram rendering and I wanted to get some things sorted for third party developer usage of Pvjs. Previously, Pvjs had three usage methods: React component, "vanilla" wrapper, and HTML custom element. The last two basically do the same thing: abstract away the React component for those that aren't using it within a React application (as in WikiPathways). Therefore, I proposed a few weeks back that we scrapped the vanilla wrapper and only concentrate on the custom element - one less thing to maintain. I've now done this and added some nifty new features to the custom element.

The custom element defines its own API that you can use to manipulate the diagram; highlighting, zooming, panning, and hiding. See the example below:

<wikipathways-pvjs wp-id="WP4" id="my-diagram"></wikipathways-pvjs>

<script>  
const elem = document.getElementById('my-diagram');  
const TCA = elem.entities.find(singleEntity => singleEntity.textContent === 'TCA Cycle');  
elem.highlightOn(TCA.id, 'red');  
elem.zoomOn(TCA.id);  
</script>  

A really nice feature of the API is that all of the highlighted/zoomed/panned/hidden entities are reflected in the custom element attributes. So, the above code will make the custom element look like:

<wikipathways-pvjs wp-id"WP4" id="my-diagram" highlighted-entities="d8bae:red" zoomed-entities="d8bae" panned-entities="d8bae"></wikipathways-pvjs>  

Each of the attributes for these manipulations is a comma separated list which is internally transformed into an array to pass into the React component. Rather than using the API to perform the manipulations, you could just change the attributes! I haven't documented this use case (yet) since I don't think many will use it and it's really just a side-effect of a good custom element API.

I'm very happy with the new custom element, if you're interested you can view the code for it here. Furthermore, I spent a lot of time making all of the documentation for Pvjs as good as I could - check it out here.

Zooming/Panning by Coordinates

It has been suggested by Alex and Anders (mentors) that the UX for the Pathway Presenter be changed slightly. Most importantly, the method for panning and zooming to diagram parts should be more intuitive. The proposal is for the user to be able to drag the diagram to the desired position for the slide and then "lock" it in place. This locked state will then be used for the slide. Currently, setting the pan/zoom state relies on zooming and panning to any number of nodes via the form controls.

To achieve the desired UX, Pvjs needs props that will tell it pan coordinates and zoom level. In itself, that doesn't sound too difficult but the difficulty comes when you consider different screen dimensions. The pan coordinates must be relative to the rendered diagram size so that when the presentation is viewed on a different screen size, the diagram is still panned to the same area. To achieve this also isn't so difficult; just set the x and y coordinates to be percentages of the diagram width and height, respectively. However, this method doesn't account for different aspect ratios which will again cause the panned coordinates to be incorrect. However, that is not an issue for Pathway Presenter since every slide is fixed to the 16:9 aspect ratio. Maybe in the future, I will try to account for different aspect ratios so if anyone has any ideas then please let me know in the comments!

Pvjs now accepts pannedCoordinates and zoomLevel props that do exactly what you'd expect. pannedCoordinates is composed of relative coordinates so { x: .5, y: .5 } will pan the diagram to halfway across the x axis and halfway across the y axis. There is also a panZoomLocked prop which, when truthy, will disable manual panning and zooming of the diagram. However, changes to zoomLevel, pannedCoordinates, pannedEntities, and zoomedEntities will still take effect. Finally, there is an onPanZoomChanged prop which accepts a function that is called with the panned coordinated and the zoom level each time the diagram is moved. This will be used by the Pathway Presenter to retrieve and persist the pan/zooms state.

Again, documentation for all of this is available on npm.

Next up

I really would like to get Pvjs up and running on the production server. It will be great to see something I have contributed to being used by many scientists, plus I'm really happy with the product. To do this, everything just needs to be tried and tested on the dev server to remove any regression errors. I really hope third parties start using the custom element and/or the React component in their own applications. So, I would like to make sure documentation is good and readily available and easily findable on the WikiPathways website. There have been a few requests for the features that I have added to Pvjs so I am hopeful that people will start using it. An iFrame is currently used by third parties to include Pvjs in their application and WikiPathways will still support this for the time being. I need to port the new Pvjs and highlighting by label/xRef into the iFrame. This won't take long at all but I will not do it until the latest Pvjs version with bug fixes is published so not to waste time.

N.B. What GSoC is buying me :)

As I write this, I am on my way to pick up a VW T4 van that I will convert into a campervan during the weekends. I've been wanting one of these since I was 16 and now I have ridiculously long hair to match. Thanks GSoC/NRNB!

VW T4 Camper

Jacob Windsor

Likes creative computer-based stuff. Web, Science, Typography, Graphics... Trying to combine too many interests into something coherent.

Maastricht, Netherlands