Introducing VizHub Beta

VizHub Beta is ready to use. Try it out! There are a number of improvements since launching VizHub Alpha.

There’s also a lot more content for learning D3 and Data Visualization — check out the list of videos here: https://curran.github.io/dataviz-course-2018/

Demo video for VizHub Beta.

This is the “University-ready” beta release. It contains the minimal feature set required for using VizHub as the tool for teaching (recording lecture screencasts) and learning (students using it for doing assignments) data visualization with D3.js in the upcoming online Data Visualization course at Worcester Polytechnic Institute that I’m teaching this Fall. In a sense this release is the “Minimum Viable Product”.

This release is mainly about new features and engagement improvements.

New Features

During this iteration, the set of planned features was aggressively de-scoped using the following question:

Can the university course start without this feature?

The new features include:

  • Auto-Save
  • Access Control
  • Syntax Highlighting
  • Datasets
  • File Management
  • Forking
  • Title & Owner
  • Profile Page

Auto-Save

Originally we had Shift+Enter as the interaction for saving. This was not very discoverable, and would need additional documentation to explain. A more intuitive option, inspired by Google Docs and Medium, is to automatically save. Since saving is current a rather “heavyweight” operation network-wise, saving only occurs after 5 seconds of idle time after editing.

It saves automatically, and tells you when it’s “Saving”, and “Saved”.

Access Control

At the time of the alpha release, anyone could edit and save anyone else’s documents. Now only the owner of a document is allowed to save it. However, anyone can still edit it (play around with the code and run the changes live), without needing to log in.

The message you see when editing someone else’s stuff.

One piece of feedback we got earlier on about Datavis.tech is that it was surprising that you had to log in and fork a visualization before being able to edit it (thanks for that Fil!). We had a scenario where I was asking for help on a piece of D3 code, and it would have been useful for others to just be able to tweak the code and see what happens, in order to help debug the situation. Now this use case has been addressed in VizHub.

Syntax Highlighting

JavaScript and CSS files are now syntax highlighted. We developed a custom theme for CodeMirror that approximates the syntax highlighting you get in Vim on Ubuntu by default, as one of the goals of VizHub is to bring the Vim-on-Ubuntu-with-Rollup experience to the Web.

Colors!

It has been a bit frustrating to get it just right though, as the CodeMirror theming is not as granular as I’d like. For example you can’t control the color of the curly brackets, and you can’t get a “property” to be one color in JS and a different one in CSS. Improving the colors is one area where Open Source contributions would we welcome. I’m not entirely satisfied with the syntax highlighting, but hey it’s good enough for now.

Datasets

Now you can upload datasets into VizHub, so that they can be visualized. The implementation is the bare minimum required to get visualization working. There is no magic, just a simple URL from which the data can be fetched.

The user interface for uploading a dataset.

After uploading a dataset, you can load it into a visualization using its permalink and the standard XHR-based D3 csvfunction like this:

const data = await csv('https://vizhub.com/curran/flaring.csv');

File Management

Now you can create, rename, and delete files. The UI is the simplest possible I could think of, and it gets the job done. Clicking on new file prompts for a new file name, double-clicking an existing file prompts to rename it, and hitting “delete” or “backspace” will delete the currently active file.

Creating a new file.

Forking

Now you can fork visualizations. This is a central idea for the platform. The hope is that after some “seed content” is created (visualization templates), forking and modifying will be the first way that people who are learning about data visualization will create visualizations.

Call to action when editing someone else’s visualization.

The way this works is that if you try to edit a visualization that is not yours, the changes will run but the content will not be saved. In this case, when the save fails (due to access control), an in-your-face message appears that says “Fork this visualization if you want to save your changes”. Clicking on it will make a copy of this visualization under your account and redirect you to edit that copy. The changes made before forking are carried over to the fork!

Title & Owner

By editing the <title>tag in the index.htmlfile, you can edit the title of the visualization. This title appears in the visualization view, as well as in your profile page listing. Near the title in the visualization view, now the name of the visualization owner is displayed, which links to their profile page.

Title from HTML, and link to owner profile page.

Profile Page

Each user now has a profile page, which shows their name and a listing of their visualizations. It’s quite bare bones for now, but it gets the job done.

Profile page with links to visualizations.

Engagement Improvements

I’ve been heavily influenced lately by this great book Scrum, and I want to try putting some of its principles into practice. We need user feedback now, and lots of it! We also need to use this feedback to help prioritize work going forward. We also want to make the prioritization and product vision more transparent, so that we can get the benefits of the Scrum approach (like increased velocity and prioritization of high-impact work) and deliver something that provides real value.

Engagement Improvements include:

  • Upvotable Features
  • Feedback Comment Link
  • Public Scrum Board
  • Open Source Contributing Guidelines

Upvotable Features

The UI elements for unimplemented features now link into their corresponding GitHub issues, so that users can upvote them and help prioritize what gets done next. This may be a turn-off for some, but it gives early adopters a chance to really participate in the development of the platform by influencing prioritization of features.

Clicking on “Search” will land you here, then you can upvote the feature with a 👍.

Feedback Comment Link

We want to optimize getting feedback from users. Especially during moments of frustration. While there are already links to GitHub issues, and folks are encouraged to open new issues, this is a rather “technical” approach for feedback. In order to make it trivial for anyone, even folks unfamiliar with the notion of GitHub or “issues”, we added a box that says “Frustrated? Comment here!” to the bottom left corner of every page.

Feedback link on every page.

This does link into a GitHub issue, but hopefully any frustrated person will feel comfortable leaving a comment there. It’s open ended, no guidelines or roadblocks like “phrase it as a user story” (like there is in the upvotable story issue template). We can take these comments and translate them into well formed issues. The overall idea is to establish an intake pipeline for raw frustrated experiences, so that we can minimize user frustration over time.

Public Scrum Board

The idea is that there should be no secret cabal, no hidden agendas, nothing behind the curtain. — Jeff Sutherland in the book “Scrum”
Our Scrum board.

The scrum board should be visible to stakeholders in the project, and I view all users as stakeholders. Therefore, it makes sense to give all users visibility into our scrum board, our active ongoing development process. I haven’t seen this level of transparency in other projects, but I don’t think we have anything to lose by trying it out.

Open Source Contributing Guidelines

One of our first issues opened by someone new to the project was a request for contribution guidelines:

It’ll be good to have a guide or a series of steps on how to contribute new features including setting up the development environment. — Bhanu

This is great! This is the sort of feedback and engagement we need! It’s a great idea, so a contributions guide was introduced, containing details of our development/collaboration workflow, how to get the project set up, and also a screencast video showing the development of the file management features.

Conclusion

You may be asking yourself:

What makes VizHub any better than what’s out there already,
like CodeSandbox or Bl.ocks.org?

The answer is: nothing … yet. At this point we’ve re-created the live coding experience you can get elsewhere, as a baseline. The next steps for differentiating the platform are to focus on Content, Community, Statefulness, and Composition.

By Content, I mean examples of visualizations, along with YouTube videos of their creation. In three months from now, examples of all the “basic” visualizations like bar charts, scatter plots, line charts and maps should all be present in the platform, as well as some interactive visualizations. The full details of planned content can be found in this post: Data Visualization Online @ WPI 2018.

By Community, I mean that VizHub should be a place in which the global community of data visualization enthusiasts can congregate and interact. One form of interaction is forking and modifying a visualization. Another form of interaction is threaded discussions, similar to GitHub issue threads or YouTube comments. Also other features like upvoting and “crowdsourced” community content curation are in the works.

By Statefulness, I mean that interactions with visualizations can create new visualizations, which take on a life of their own. For example, consider like this Scatter Plot with Menus. The act of selecting which data columns map to X, Y, Color and Radius creates a new visualization (without coding). Imagine if that new visualization could be captured, saved, and shared.

By Composition, I using components from existing visualizations to create new visualizations. For example, one could rapidly prototype an interactive dashboard with multiple linked views by composing components from “The Basic Bar Chart”, “The Basic Scatter Plot”, and “The Basic Line Chart”, without re-implementing the components from scratch.

These are the goals for Content, Community, Statefulness, and Composition. I want to thank Elijah Meeks for the insights into how these particular aspects could really differentiate VizHub from what’s out there, and fill an actual gap in the market of online coding & data visualization tools.

If you’ve read this far, get involved! Please take a look at our public backlog and give a 👍 to the issues that look the most interesting and useful. Give VizHub a spin, vent your frustrations, or share ideas for new features. Thanks!

Like what you read? Give Curran Kelleher a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.