The technologies that became the world wide web were originally created to facilitate communications between researchers. One of the great ironies of digital age is that while the web has transformed nearly every aspect of our lives, it lags far behind in its original mission. Communications between researchers still make the PDF the default format for scholarly articles. Communications from researchers to the public tend to rely on general-purpose content management systems, and there is a lack of dedicated tooling needed by researchers and science communicators.
One area where the current web lags far behind its potential is the visual display of quantitative information. Web pages are documents, but they are also software, meaning that any data graphic can be rescalable, interactive, and directly linkable to the underlying data. Yet many charts on the web today provide a poor experience for users: they are often to load due to heavy resources, portray data inaccuately, are illegible on mobile devices, or all of the above.
Why is this? Creating data graphics, even for a print publication, has always required a rather broad suite of knowledge: from mathematics and statistics, to aesthetic design, to domain-specific knowledge of the data being shown, to familiarity with the necessary software, to detailed knowledge of charts and chart types. The web complicates this further by introducing the demands of responsive design and accessibility, and the potential for interactivity. Making it work well requires the skills of designer, developer, and scientist.
I aim to provide the "missing link" to make the visual presentation of data work well in a world of screens. With a PhD in molecular biology, my educational background is based on explaining, presenting, simplifying, and streamlining complicated topics. I understand what data say and what they do not. I have also been building for the web for nine years: I have a deep the current ecosystem, in a wide variety of languages and systems. I not only understand what data mean: I also know how to host it, munge it, transfer it to a browser, display it, and make that display work as well as it can for the user.
These are general guidelines to how I think about data, user experiences, and programming in general.
-
The purpose of data graphics is to clarify, not confuse (the Edward Tufte rule). While numbers do not lie, many data graphics mislead by valuing aesthetics too highly. Some mislead intentionally. The purpose of design is to make something usable. This should be our primary value in designing data graphics just as much as it is for designing forms or navigation menus.
-
As simple as possible but no simpler (the Albert Einstein rule). Not every graphic needs to be interactive. Not every website needs the latest framework. The less code written, the less potential for bugs.
-
Meet the user where they are (the Donald Rumsfeld rule). There are mobile and desktop browers, screen readers, search engines, social media previews, reader mode, AMP, and RSS. Users can zoom pages, install browser plugins, and clip, save, or repost content. Creating a perfect experience across every context is impossible, because of the "unknown unknowns". Stick to solid fundamentals, and web standards.
-
Shorten the feedback loop (the Dave Thomas rule). Produce working software, no matter how simple, right from the beginning. Write tests. Start with something small and good, and work on making bigger. That's way easier than starting with something big and bad and trying to make it better.
-
Be curious. Ask questions. Read books (the Julia Galef rule). I like what I do because I work with a variety of clients and projects. I can't know everything there is to know about the web, just like I can't read every paper published that might be interesting. No one is an expert on everything, and being afraid to ask questions is just ensuring future ignorance.