VizHub 2.0 Kickstarter
Everyone with an Internet connection should be able to learn how to code.
For free.
Data visualization is one of humanity’s most powerful tools for making sense of data, and therefore making sense of the world. That makes data visualization one of the most impactful kinds of coding one could do. For this reason, everyone with an Internet connection should be able to learn how to analyze, design, and code data visualizations. For free. At least, that’s what I believe, and that’s why I’m working on VizHub. VizHub provides the missing platform to achieve these goals.
I’m building the next generation of VizHub — “VizHub 2.0”.
This post is a copy of the Kickstarter campaign — check it out!
VizHub is a Web-based application for data visualization and creative coding that can be used by students, teachers, and professionals. I’ve already developed “Version 1.0” (Minimum Viable Product) and used it to teach my 2018 online Data Visualization graduate course offered through Worcester Polytechnic Institute (which FreeCodeCamp just released as a 13-hour video). I’ve also used VizHub during data visualization workshops I’ve delivered in-person for both corporate training events and events open to the public such as Data Visualization Foundations at Stamen Design. Regardless of the merits of VizHub 2.0 itself, if you have benefitted from my work and the free online educational content I’ve created, please consider backing this Kickstarter as a way to say “thank you”. Thank you!
So, what are the merits of VizHub 2.0? What makes it better than other things out there? Well, let’s start with the question “Who would use VizHub?”.
The vision is that VizHub can be a tool that people at all levels of their programming and data visualization journey can use. From novice students just learning to code, to college students learning new frameworks and libraries, to teachers and delivering live-coding tutorials, to professors visualizing their research data, to freelancers working with clients to evolve visualization works, to small teams developing data visualizations (comprised of managers, admins, designers, engineers, and clients), to enterprises who need a unified platform for executing large scale data visualization initiatives.
Existing software that has made huge strides in the space of online code editing includes: Observable, Bl.ocks.org, Blockbuilder, CodeSandbox, Glitch, CodePen, JSBin, Plunker, JSFiddle, and to some extent GitHub. While many of these overlap with VizHub in the feature set provided, none of them provide the “perfect blend” I’d like to have for data visualization education and practice. I have actually used used Blockbuilder (at WPI in 2017) and JSBin (at MIT in 2012) as the platform for courses I’ve taught in the past, and they left much to be desired. Let’s examine exactly what was left to be desired, by looking at what our various personas would do with VizHub.
In an education context (e.g. university course, workshop, or one-on-one mentorship):
- The Student needs to study visualizations & lecture videos, fork & modify visualizations (to perform their assignments), present their work as assignment submissions, and share their work with the class. Students also need to be able to freely experiment, explore existing works, and participate in discussions.
- The Teacher needs to be able to record lecture videos (while live coding), present visualizations to students, add lecture videos to visualizations, organize content into collections, and give feedback on student work.
- For one-on-one mentorship, the Student and Teacher require real-time collaboration to effectively work together. The teacher needs to be able to “hand over control” to the student.
Within teams (or if you’re a freelancer, you’d need to wear all of these hats):
- The Manager needs to review work by the team, leave feedback comments (for the Engineer or Designer to act on), participate in discussion threads, organize collections, and share visualizations with The Client.
- The Admin needs to manage organizations and teams.
- The Designer needs to review work by The Engineer, make tweaks to the visual design (using the Visual Editor), leave feedback comments and participate in discussions.
- The Engineer needs to develop software in-platform (use the Code Editor), import/export out-of-platform work (e.g. GitHub), present work to the team, receive feedback from the team, and participate in discussion threads.
- The Client needs to review visualizations by the team, leave feedback comments, participate in discussion threads, embed visualizations in web pages, and export work for downstream workflows.
For a tool to be useful for all these personas, it must have all features listed. If it doesn’t have each and every one of these features, then it excludes one or more personas. This is why it’s important to develop VizHub. On the surface, VizHub is “yet another Web-based IDE”, but the deeper motivation behind it is to support this specific set of personas, and target the field of data visualization in particular.
Let’s talk about the features VizHub 2.0 will have, and why each is important.
The Code Editor feature is required for Students, Teachers, and Engineers. The code editor must be able to give instant feedback when changes are made (unlike GitHub’s Pull Request and GitHub Pages redeploy workflow). In order to be compatible with existing real-world projects and be exportable to downstream workflows, ES6 modules should be supported.
VizHub will have a unique “Visual Editor” that lets users make changes without writing any code. For example colors (using a perceptual color picker), numbers, booleans and strings can be made editable. This feature will be useful for exposing “tweakable” things. This feature will allow personas who do not have coding skills, but have an interest in making minor changes, to help evolve works. For example, this would be particularly useful for The Designer, The Manager, and The Client.
The features Presentation, Forking, Discussions, and Real-time Collaboration sort of “hang together”, and are particularly useful for education contexts.
- Presentation refers to the ability to present a visualization while emphasizing the visual aspects, and de-emphasizing or hiding completely the code and technical aspects.
- Forking refers to the ability to create a copy of an existing work, such that you can then modify the copy (which resides under your ownership).
- Discussions refer to a linear thread of comments, similar to those in GitHub issues or the YouTube comments section. This feature will be critical for enabling users to give and receive feedback, which itself is critical to the data visualization process.
- Real-time Collaboration refers to the feature set in which “collaborators” can be given edit access to a visualization, and changes are propagated instantly to all collaborators (and non-collaborator viewers as well). Think Google Docs, but for code files.
Export refers to the ability to download a file (usually a .zip file) that contains the source files behind the visualization. The exported file should be runnable externally in a local development, without any dependency on the platform.
Embed refers to the ability to include the visualization as an embedded object within any existing Web page. For example, placing a visualization inside a blog post or news article. A distinction can be made between Embedding with Linkback, where the embedded frame includes (is “polluted” with) a link back to the original VizHub page, and White-label Embedding, where the embedded frame contains purely the visualization itself, without any additional link back to VizHub.
Metric of Popularity means some way to tell how popular a given work has been. For example, this could be view count, number of “hearts” or “stars”, or number of forks. In VizHub, this will take the form of “upvotes”, which will also have their negative counterpart “downvotes”, which will be paired with some UX flow to encourage constructive criticism.
Collections refers to the ability to assemble linearly ordered sets of works. For example, one lecture of a course showing the evolution of a visualization could be one collection. A collection could groupd works according to themes. In principle, a single visualization could belong to multiple collections. In a sense they are similar to YouTube playlists.
Private Works refers to the ability to make it so only permitted collaborators can view a given visualization. This is distinct from “unlisted”, in which anyone with the link can access.
Manage Teams refers to the ability to create and delete teams, add users to teams, remove users from teams, and edit permissions of team members.
So, that’s an overview of the features that VizHub 2.0 is slated to have, and why.
The VizHub home page lists new visualizations created by users. I’ve noticed a steady stream of about 10 or so new visualizations being created in the platform every day. These are mostly forks of my work with minimal or no changes, but some are completely original content. As it stands, VizHub has the bare minimum feature set to make it useful for students and teachers. Most of the users appear to be newcomers to coding who are using the platform to learn the basics and experiment.
The count of unique users has been continually increasing since VizHub was launched in August 2018. This is reassuring, as it validates that there is a place in the world for a tool like VizHub, and there are people who would use it.
In VizHub, visualizations can only be created by forking existing visualizations. This leads to a tree of content that can serve as a map of the content space. This foundation also seeks to leverage the “Fork & Modify” style of collaborative development that has made Open Source such a success. In fact, all public content in VizHub is MIT Licensed, making the platform friendly to those looking to export works out of the platform for downstream workflows and integration into commercial products.
Additionally, VizHub supports industry-standard development practices such as ES6 modules, and does not introduce any VizHub-specific language or primitives. This makes VizHub content easily exportable and directly interoperable with existing codebases. Also, VizHub currently supports React with JSX. I hope to make Svelte 3 work inside VizHub as well, as its reactive programming model is quite compelling.
Why not just use Observable?
Observable is probably the closest thing to VizHub on the market today. I have huge respect for the amazing work that’s gone into it, and the community that has sprung up around it. There are however a few “show stopper” issues that turn me off from using it, particularly in an education context.
The primary issue for me in a teaching context is that Observable is not JavaScript. Students IMO have enough to learn already when exposed to JavaScript, CSS and HTML for the first time, and I’d rather not add another layer of techniques and syntax to learn (even though they are all ingenious productivity-enhancing things). When it comes to exporting code and integrating work from Observable into existing codebases, there is significant added complexity. It’s probably as simple as it can be, given the contstraints at hand, but I’d prefer to leave students with something “vanilla” that they can easily use outside the platform.
The secondary issue for me in a teaching context is that the license on public work found in Observable is not a permissive Open Source license. This means that exporting or copy-pasting code out of Observable is essentially using unlicensed code, unless the author explicitly declares an Open Source license in the notebook, which I haven’t seen done very often. Forking & modifying unlicensed code is something I’d like to steer clear of recommending to students. For class projects it may be just fine, but in a professional setting it can be problematic. This is why VizHub will take the same approach as CodePen: all public content is MIT Licensed.
That said, I really mean no disrespect for Observable. It’s an amazing platform that has some very futuristic features, especially the reactive runtime and interactive notebook model. The Suggestions feature is great for asynchronous collaboration. For more on what makes Observable great, check out this post Why Observable?.
What’s new in VizHub 2.0?
User interface design has always been something I’ve struggled with. In recent years I’ve come to realize that I’m more of an engineer, a software craftsman if you will. I’m just not that good at user interface design. I found that I much prefer working on a team, where there is a dedicated designer to generate pixel-perfect visual designs that I can then go and implement. Having had great experiences working with Stamen Design on many projects over the past two years (in particular their amazing designer and project director), I hired Stamen Design to work on UI and product design for VizHub 2.0.
Real-time collaboration is another core feature that VizHub 2.0 will have. Think Google Docs for code. I can’t count how many times I’ve been remotely mentoring someone, teaching a live event, or working with clients where the delay introduced by having to make a new Git commit and re-deploy stood in the way of doing things. For example, when I’m mentoring someone and live-coding in their project, I want to hand over control to them when they have an idea or know how to move forward. As another example, when client asks something like “Can you make that blue slightly brighter?”, I want to be able to make the change and have them see it instantly, rather than saying something like “Sure, I can do that after the call and let you know when the change is deployed”. I’ve built out already a rough implementation of real-time collaboration for VizHub 2.0, and feel the path forward for developing this feature fully VizHub is clear.
With real-time collaboration comes the opportunity for “presence” features. For example, showing where the cursors for the other users are, and showing what text they have selected. In collaboration with the ShareDB Open Source community, I’ve helped put together this prototype of real-time collaboration with presence cursors and selections. This brings presence features one step closer to implementation within VizHub. Other presence features slated for development are listing which collaborators currently have the visualization open, and showing what file they are looking at.
The ability to edit code on smartphones can open up the possibility of programming to a vast population of people, particularly in India where mobile computing dominates. This is something I’d like to make possible with VizHub. For example, I’d like to be able to run a visualization workshop in which the audience brings their smartphones, not their laptops. I want to be able to have participants fork & modify a visualization live, then share their work with the group on Slack or Twitter, using only their smartphones. This capability would open up the door to teach coding skills to those who would otherwise never be able to write a line of code in their lives (for example, in remote villages in India where no one has a single laptop or desktop computer, but everyone has Internet-connected smartphones).
Imagine then that a student shares their work in progress and I open it on the projector for everyone in the workshop to see. I could then point out a minor improvement to be made, and the student could make the change instantly on their smartphone, and as they type, the changes would be broadcast to my computer in real time, and be shown on the projector to everyone in the room. This is the sort of thing I want to make possible.
User interface design has always been something I’ve struggled with. In recent years I’ve come to realize that I’m more of an engineer, a software craftsman if you will. I’m just not that good at user interface design. I found that I much prefer working on a team, where there is a dedicated designer to generate pixel-perfect visual designs that I can then go and implement. Having had great experiences working with Stamen Design on many projects over the past two years (in particular their amazing designer and project director), I hired Stamen Design to work on UI and product design for VizHub 2.0.
The work was highly collaborative (lots of whiteboarding and talking through flows), and was done when we were all physically present at the Stamen office in San Francisco during a single week. I’m personally totally thrilled with the resulting designs. This gives me a huge amount of “ammunition” to draw from while doing the engineering work. Even though not allfeatures have been fully designed, these designs are definitely enough to build out the core of a fresh new implementation, and the visual design language here can be extrapolated to more features in the future.
Unlike the VizHub 1.0 codebase, the VizHub 2.0 codebase will not be Open Source. In making the original codebase Open Source, the hope was that users would actively participate in development of the platform by doing things like opening new issues, commenting on existing issues, and even opening Pull Requests to make improvements. None of that happened. Garnering only 32 stars to date, VizHub as an Open Source project has been a complete flop. Having the codebase Open Source introduces many problems with developing it into a commercial product as well, which is the next phase for VizHub.
Although the VizHub codebase itself will not be Open Source, the public content of VizHub will be (clearly marked as MIT Licensed). In this way, similarly to GitHub, VizHub will foster the growth and flourising of Open Source content, for data visualization, creative coding, and whatever other areas of development VizHub users pursue.
The roadmap for development is to implement the new designs from Stamen during July and August 2019. Beta testing will begin in July. I will use VizHub 2.0 Beta to teach the online graduate course, and the students will essentially be beta testers. The hope is to launch VizHub 2.0 publicly, with Pro features working, in Q1 2020. Beyond that the Teams and Enterprise features will be developed.
I’ve become a huge fan of Scrum, a framework for “Doing twice the work in half the time”. A huge part of Scrum is getting feedback from actual users as the software is being developed, and delivering incremental improvements at consistent intervals (largely based on that feedback). VizHub Beta testers will be given access to the new re-designed VizHub as it’s being implemented, and will also receive a newsletter each sprint detailing fresh incremental improvements. The forum will serve as a place where beta testers can provide feedback (especially pain points), to inform what should be worked on next and to bring up usability wrinkles that need to ironed out.
My time tracking software tells me I’ve already invested over 500 hours into developing VizHub. I feel like it will take about another 500 hours to develop it into the complete vision I have for it. This is why I’m turning to Kickstarter — to raise funds so that I can focus full-time on VizHub, and not have to dilute my time over the next year or so with paid projects and put VizHub on the back burner yet again (as I’ve had to do many times to stay afloat).
Ideally I could raise enough funds to hire additional people to work with me on developing VizHub. If I did have cash to burn on VizHub, the first thing I’d do is hire Stamen Design again to help build out visual designs for more advanced features. I’d also hire additional developers to help with the engineering work, which I’m currently doing all alone. I’d hire a marketing specialist to help grow the user base of VizHub. Eventually I’d hire a product manager as well, to take my place as the one driving and prioritizing the set of features to be developed. At that point I could step back from VizHub development, and just use it for what I love to do, namly data visualization projects and teaching.
Thanks for reading. Back the Kickstarter to become a beta tester!
