Here are some issues I encountered with cross-browser testing:

1. On Safari 8.0.7 on OS X 10.10.4, scrolling through the code doesn't expand the code view.

2. On Firefox 39.0.3 on OS X 10.10.4, the scrolling for the code box works but the focus doesn't reset to the result view on hover.

There are potentially more that I haven't found, so feel free to leave a comment on this PR if you find other bugs. Thanks!

when we have a problem saving or other app-level problems we should let the user know via a modal, rather than silently failing as we do now (console.logs aren't enough...)

we can make something like https://github.com/rackt/react-modal available on the app to make it easy to throw up a modal from anywhere

This gist loads fine in bl.ocks but not in the demo because d3 code is in separate js.

If functionality isn't in roadmap to support loading files outside of index.html, an error should be thrown.

this makes using the back button impractical for navigating between forks. I believe its a feature of the react-router, but I havent looked into it yet.

Let's figure out what html should be included by default in a fresh block.

Currently the most important thing would be the cdn link for d3.js

The text editor should not rely upon newline characters for its height. And it should have a minimum height even if there is no content.

When the file is only 2 or 3 lines, then it becomes quite difficult to work with it.

I'm looking at the Matrix: Reboot example, and the README is just barely too long to fit in the rendered markdown view panel. When I try to scroll, the source area scrolls up over the README. I would like some way to see the entire rendered markdown.

New blocks created with blockbuilder should have a link to fork this block. This will reduce the friction of having to properly modify the existing url for blocks on bl.ocks.org.

I'm not sure how obvious it is to people to know they can just drop an existing block into block builder to start editing it. might help to add a call to action or something on the home page.

It would be great if, upon creating a new block, the margin convention was set up for me.

It would also be cool, though less essential, to have some basic D3 code to copy and work with. It shouldn't be took complicated that it takes more than a moment to understand.

Because we count on loading the raw data from github our edits aren't immediate, and that isn't obvious.

If you add data.json to the block via the file adding UI, it will save and reload the page. Let's say you have an error in the json file, or want to edit it slightly. Edits will seem like they are refreshing the display, but aren't actually doing anything. If you click save and reload the page you will see the results, but that sucks.

potential hacky but seamless solution

hijack d3.ajax and short-circuit the function to return text found in the file contents rather than a real ajax request.
This would mean injecting some javascript after d3 is loaded but before the user code is run... and would only work with d3 function calls. If this solution breaks for some reason it would be very unclear to the user why their code is broken.

worse UX but simpler solution

Make it very clear in the UI that editing files requires a roundtrip. Make it easy for the user to save+refresh from the file editing ui?

I have tried using simple plugin extensions for chrome like "Search & Replace" to be able to do basic tasks like finding a name and replacing all instances with a new name. Unfortunately these don't work to well (at least in my hands). Would be great to know how to maybe implement some extra text editor capabilities. Thanks.

Currently certain state changes cause the iframe to rerender when it doesn't need to.
Namely the editing of the gist's description.

indicate to user that there is something happening

this could be useful for keeping a certain file tab open when refreshing or embedding. could also use it to control rendering of code & display windows (sidebyside vs. standard vs code only vs display only)

building-blocks does not support url() resource pointer, and fails quietly

Often after using a slider I just want to get back to the original value, especially if I'm just using the slider to explore what the value affects visually. But, by the time I stop sliding, I've lost the original value. The only way to get back is to do a ton of "control Z".

Would be nice to have a way to keep track of the original value and easily get back to it. And/or to see the diff and choose if I want the new or old value.

Building-blocks don't allows me to upload a second JS file or a JSON file.
On this http://bl.ocks.org/jkutianski/0601ad01f560d49a5967 I can't upload d3.selection.template.min.js and on this https://gist.github.com/jkutianski/6591596 I can't upload argentina_indec.json file.

Need to add the same fix we used for fetching to the save code when the user isn't logged in

Description

The slider widget stays on the screen when clicking a numeric value in standard mode and then switching to side-by-side mode.

Steps to reproduce

1. View a project
2. click a numeric value (such as font-size, width, margin-top, etc)
3. switch a to side-by-side mode

Observed behavior

The slider widget stays visible on the page, and can not be cleared.

Expected behavior

The slider widget should be cleared from the page.

Environment

I am using Firefox 40.0.3 on Xubuntu 15.04.

problem

Files over 1mb get truncated by the gist API
https://developer.github.com/v3/gists/#truncation

Since we are currently relying solely on the client's version of the gist this will break forking/saving of blocks with large files.

Keep in mind that we can't fork using the gist API for 2 reasons:

1. we want our fork to include local modifications
2. github won't let you fork your own gists

potential solution

According to the docs we can use the raw URL to download the file up to 10mb, after that we would need to clone the gist using git. So for any block with files larger than 10mb we need to throw up our hands (the size of each file is included in the gist data). For files between 1mb and 10mb we need to add extra logic to download the data so we can properly fork from the client, and we need to let the user know whats happening as it will probably take a while to download the data before they are able to fork.

only allow thumbnails to be added for saved gists.

improve UI for cropping/resizing image

The positioning is messed up by the layout probably.
Should figure out how to remove sliders when UI state changes as well.

Probably need to up the z-index for tooltips for divs block__site-nav & block__mode

I've gotten some good feedback about adding more explicit annotations when a user first comes to a block (or the homepage). These could be in the form of small text call-outs to the right of the block/code as well as tooltips:

• click me to popup the renderer, or hit esc while editing
• this is the output, this is the code
• gist/block navigation explanations

I'm not sure what is going on, but when I leave out the protocol from the include (e.g. removing the https: part from https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.5/d3.min.js to make the line <script src="//cdnjs.cloudflare.com/ajax/libs/d3/3.5.5/d3.min.js"></script>, the program doesn't render any html.

I have a hunch this is a trivial bug, but can definitely be a showstopper for someone just trying to learn.

Handlebars doesn't seem like it's used for much. remove?

https://github.com/enjalot/building-blocks/blob/master/views/base.handlebars#L1

It will find skyrocketing beta adoption if its demo could be permanently hosted as well which could be updated with the most stable version (based on npm semver's minor digit).

Lets discuss ideas around this topic.

Adds some more notes for deploying files

We should detect state changes in the gist and then warn people before they navigate away (accidentally clicking back, clicking the "new" button etc).

From a discussion with Nils:

1. Some sort of different background color / subtle indicator for the mouseover area when the code is fullscreen to provide affordance to the user that something will happen if they mouse over it
2. Immediately showing / hiding the block is slightly jarring - perhaps a quick transition would make it so when the block canvas area appears, it's not as jarring
3. different icon / symbol / text for the side-by-side. Perhaps we can start off by using more labels, and then imrpove over time reducing the number of labels (explict vs. implict - try to keep the UI as unambigious as possible). At a bare minimum, all labels / images should have a title tag and images an alt tag

Create a gallery like http://bl.ocks.org/mbostock to quickly navigate a user's blocks.

we should investigate filtering the results by the presence of an index.html (to remove gists that are not intended to be blocks)

Description

When making a code change in a block example, the display does not update to reflect new changes.

Steps to reproduce

1. View a project
2. make a code change

Observed behavior

The rendered result stays the same until some page event, such as switching to side-by-side mode, causes re-render.

Expected behavior

The rendered output should change to reflect the state of the code, or the user should be encouraged to manually refresh the output.

Environment

I am using Firefox 40.0.3 on Xubuntu 15.04.

We should investigate using mozilla's hosted solution vs. running our own:
https://togetherjs.com/

also I haven't tried it out locally yet to see how it would interact with the UI, but if it can be fit in this could be really cool

if we change the public: true property to false before we fork/create a gist it will be made private (meaning only people with the link will be able to see it). We could provide some special UI indications that the gist being viewed/edited/saved is private.

Description

The slider widget does not render when clicking a numeric value in side-by-side mode.

Steps to reproduce

1. View a project
2. switch a to side-by-side mode
3. click a numeric value (such as font-size, width, margin-top, etc)

Observed behavior

When clicking a numeric value, the cursor is placed at the point of click.

Expected behavior

The cursor should be placed at the point of click and a slider should render above the value.

Environment

I am using Firefox 40.0.3 on Xubuntu 15.04.

Since building-blocks directly replaces script references to local files with code, the defer attribute in script tags does not work (it only works with non-inline code). This can create issues with blocks where there are internal and external scripts with defer tags; the internal scripts will load and execute before any external scripts with the defer tag, which may not be the intended behavior.

Example of the issue. MDN reference to script/defer.

This way you don't risk losing work when you realize you haven't logged in.

It is possible to login via a different tab, the cookie will then be valid but nobody will really discover this or risk trying it.

We can add metadata to a blockbuilder page so that it has a nice description and thumbnail when shared on slack or twitter: https://dev.twitter.com/cards/getting-started

e.g.

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@nytimes">
<meta name="twitter:creator" content="@[TWITTER NAME]">
<meta name="twitter:title" content="[TITLE]">
<meta name="twitter:description" content="">
<meta name="twitter:image" content="http://graphics8.nytimes.com/images/2012/02/19/us/19whitney-span/19whitney-span-articleLarge.jpg">

this will likely involve rendering the tags using handlebars

See sample at http://blockbuilder.org/mr23/f50b395446ecbc1a25e9
or just drive the slider for noZero below zero.
For example, it results in :
.-41
instead of
-.41

Once I receive all of the survey results I can add backer names + links to the about page.

Many (of mbostock's) example blocks have a required file with a relative path, especially for geo examples.

For example: Coastal Graph Distance
http://bl.ocks.org/mbostock/9744818

When bringing it into building blocks, it just shows up blank. :(

The path is passed to d3.json as: "/mbostock/raw/4090846/us.json"

I'm not sure what the answer is, but should be handled in some way. On a simple level, maybe just a warning message. Better if there is a workaround to bring in the file somehow. Best if something happens automatically to make it work :)

I made all files that weren't the index.html or README.md editable via HTML5 textarea rather than using CodeMirror. This is mostly to avoid performance problems when trying to render large csv or json files. For external code files we should easily be able to support new editor instances (e.g. for .js or .coffee, maybe even .jsx, .jade etc)

You can see how the editor components are loaded dynamically depending on which file is being used:
https://github.com/enjalot/building-blocks/blob/master/public/js/components/editor.js#L50

the implementations for HTML: https://github.com/enjalot/building-blocks/blob/master/public/js/components/editor__html.js
Markdown: https://github.com/enjalot/building-blocks/blob/master/public/js/components/editor__md.js

One of the reward tiers was to allow backers to choose their favorite block for inclusion in a special gallery. Once I receive the list of blocks from the backer survey this page should be quick to construct!

You might want to add a note and a link to the kickstarter page for the folks who land on this repo through other channels (for instance seeing it starred by a friend).

Currently, the file-switcher is non-existent and is basically a set of links at the bottom of the page which links directly to Github. Here's what it looks like right now:

Here's what I'd like it to look like: (note that this will be at the top of the file and not the bottom, also, ignore placeholder text)

I'm fairly confident that both me and @enjalot want the files to show up in the tab on clicking on them, but I'm not sure about the 'More' dropdown.
Should we have a dropdown? Should it try to render the files locally to the best of its ability or redirect to the raw Github file like its doing right now (might be beneficial if the file is 200 MB for example)? Thoughts and suggestions greatly welcome.

Also, what tab switcher should we use? I quickly hacked up the prototypes based on the Bootstrap tab switcher, but maybe there is a better one that doesn't require importing such a huge library?

Anything else I may not be considering? Thanks!

It would be nice if there was a global "duration" property and any change in a style or attribute was actually transitioned to the new style/attribute, rather than a complete rerendering.

I realize this is a major feature request, but animated transitions are in data visualization because we know it helps people to follow how one thing changes to another.

It's hard to find where your error is because the code loaded in from the blob doesn't have a map to the line number you are working on in the editor.