Moving Squares: a d3.js experiment

Although d3.js is intended to visualise data (d3 stands for Data Driven Documents), it can also be used to render interesting visual effects when you decide to generate your own data. I was looking for a way to add something visual to the layout of this website, and decided to try something I had been thinking about for a while now: using d3.js to build patterns by repeating geometric shapes.


In the end I thought the result is too busy and distracting to have running in the page constantly. I do like the it looks and how it animates, so I decided to add it as a part of my portfolio. The animating result can be viewed at

Fq_delta: efficient storage of processed versions of fastq files

Next Generation Sequencing (NGS) is a new technology to research biological processes and genetic properties of organisms. NGS generates much more data than older technology – up to terabytes for one experiment. And the technology is still improving: on average every five months, twice as much data is being made available. This data is usually stored in fastq files.

Although this offers exciting new possibilities for researchers, it also poses a challenge: how can researchers store such vast amounts of data? During my graduation-internship at the Viroscience Lab of the Erasmus Medical Centre in Rotterdam, I was asked to look into this problem.

One part of my work revolved around deduplication of data. During research the data may be processed in several steps before the actual analysis. However, those steps are not set in stone. Both for practical reasons and to improve reproducibility, researchers at the Viroscience Lab would like to store a version of the data after each step. In normal circumstances this would require more and more storage capacity.

I developed fq_delta: a python module to store differences between versions of fastq files. It uses the google-diff-match-patch library, which in turn implements Myer’s diff algorithm. Where traditional diff algorithms are either line or block based, Myer’s diff algorithm is able to detect changes at the character level. For the type of data and types of changes involved in NGS, this is much more efficient than for instance diff or rdiff. Tests have indicated that processed versions require less than three percent of the original file size.

Fq_delta creates delta files by cycling through both original and processed files.

The module offers a class that acts like a file-like object, so fq_delta can be used in conjunction with a module like Biopython. The module also installs to commandline scripts that allow the user to stream data to and from fastq processing tools like cutadapt or the FASTX-Toolkit.

I’ve written a technical note on fq_delta which is, at the time of this writing, under review for publication. The module itself is available for download at The rest of my graduation internship involved a review of several dedicated and general-purpose compression applications, and an advice regarding the future of the faculty’s ICT infrastructure.

EZIS Mobile: Simplifying Workflow for Nursing Staff

The main project for the Interface & User Experience Design minor consisted of a assignment from a design firm for an actual client. In our case the assignment came from Fabrique. We were asked to design a mobile application for the nursing staff of University Medical Center (UMC) Utrecht, to improve their daily workflow.

Patient data is stored in a centralized database: the Electronic Hospital Information System, or Electronisch Ziekenhuis Informatie Systeem (EZIS) in Dutch. At the moment of this writing, this information can only be accessed through a desktop or laptop computer. However, not all departments have Computers on Wheels (COWs) available, and in many cases they’re not even practical. So during rounds, most nurses rely on pen and paper to have an overview of their patients and keep track of all measurements they do throughout their shift.

Because this is impractical and error prone, the brief called for an application that would allow a nurse to enter new measurements directly into EZIS. It should also display previous measurements, so the nurse can also see trends for all measurements. During our research at the start of the project, it became clear that nurses not only write down measurements but also a lot of other patient data, like their history and medication. An app that focusses merely on measurements would only add to the tools used during the day, instead of actually simplifying a nurse’s workflow.

So we expanded the app’s functionality to include all data that nurses currently access during a shift. We present this data in several forms, depending on the nurse’s current activity. For instance, at the end of a shift a nurse discusses the patients with a nurse whose shift has just started. The app offers a brief overview of all patients, including measurements that have been marked as noteworthy.

Designs for EZIS Mobile

The original title of the project was NurseMapp, short for Nurse Measure App. We decided to go with a different name: EZIS Mobile. Though not extremely original, it communicates our intentions: ultimately this app should feel as a true and complete extension of the central EZIS. The brief described this app as the first of many. We believe a centralized but modular approach would better serve all staff within the hospital.

A “Making of” was designed for this project in the form of a one-page website, in Dutch. It describes the structure of the project and the decisions that were made along the way. You can find the Making of, including a working prototype of the final design, at

Designing the User Experience: building an interactive Funnel Diagram

During the minor Interface and User Experience Design, we were asked to pick a method out of the HCI Toolkit at random, research the method and write a paper on the subject. The method I drew was the Funnel Diagram. A lot has been said about how to interpret funnel diagrams and what can be done to improve the conversion they depict. But during my research I discovered there really isn’t that much to say about why a funnel diagram should be used and how it should be designed. In Communicating the User Experience the authors Richard Caddick and Steve Cable give thorough and well substantiated instructions on how to design a funnel diagram.

Part of the assignment was to give a short workshop on the subject, including the demonstration of a worked example. Because there wasn’t that much to tell about how to make a funnel diagram, I decided to put some extra effort into the worked example by building a tool that would allow anyone to make a funnel diagram in a few minutes instead of the usual several hours. It offered a great opportunity to start exploring d3.js, a JavaScript library for manipulating documents based on data developed by Mike Bostock. The tool is now available at for anyone who would like to use it. If I find the time, I’d like to revise the code and make it available through github.

Funnel Diagram

Although this tool gave me something to demo during the workshop, I still really didn’t know what to write about. After showing the tool to my teacher Jasper Schelling, he showed me some of the work and ideas of Victor Bret. In particular, Jasper pointed out Bret’s ideas about what he calls explorable explanations and reactive documents. These offered extra ideas to implement in the tool, but also a direction I could take with the paper I was about to write. We came upon the idea of building more tools for the methods in the HCI Toolkit.

The Funnel Diagram is one of those methods where the finished artifact associated with the method offers insight into the design of a product. However the process of creating the artifact doesn’t add anything at all, even though the process takes up significant amounts of time and attention. Contrast this with the method Mind Mapping, where the process of creating the artifact (i.e. the mind map) provides the insight or ideas. By building tools that make light work of creating artifacts, the cost of implementing the associated methods would become significantly lower. This could lead to methods being applied more often, which should ultimately lead to better designed and developed solutions.

I’ve written the paper about these ideas and posted it on this site. If you’re interested, please read Let’s put the “Tool” into “HCI Toolkit”.