I want to learn D3. I don`t want to learn Observable. Is that ok?

Wow. Have you thought about just picking another library, or at least considered different perspectives than your own as being equally valid?

1 Like

stop spending their free time

So in short, you want Mike & al. to stop publishing any new D3 examples?

There’s nothing stopping you from using whatever version of D3 you were using before into perpetuity, and never looking at an Observable notebook.

Observable is completely extraneous to D3 and coupling it with learning D3 is only helpful if you intend to continue with Observable

You are making emphatic, categorical statements, but in my opinion this is misguided at best. Working with notebooks when learning an API is extremely helpful even if you never intend to publish a notebook in your life. It changes documentation from a pile of dead static text into a living interactive playground. (If you like static text better though, there are a variety of printed books available about D3.)

Most developers, particularly in industry, have no need for Observable and it’s a serious hindrance to learning D3 ,

You are dramatically overselling this. It’s a serious help to learning D3. The only thing it is a “hindrance” to is naïvely copy/pasting an unmodified example into your own project without bothering to read or understand the code. But even then, it’s more of a speed bump than an obstacle.

my choices are to 1) get out before it gets worse, 2) learn Observable well enough that I can decrypt it for my own purposes, or 3) accept the new environment and all that it will entail going forward.

Or option 4 you (possibly along with other people) could pay money to fund creation/translation and publication of non-notebook examples. I’m pretty sure if you pay fair market salary you can find someone to do this work for you.

4 Likes

IMO the best course of action is to continue development of Observables and D3, but to create a separation with the official documentation. It should be up to the user to decide whether he or she wants to delve into Observables. At this point it’s not an option. People have done without Observables for years, d3 evolved and some stuff is deprecated. Forcing someone to learn Observables only to update his project with the new stuff (eg. join vs the old enter-update pattern) because the documentation is rigidly bound to Observables is pretty bad.

I would happily donate if the documentation is written with plain browser JavaScript in mind.

I’m afraid you might be missing the point: D3 isn’t just about joins, and the documentation in its current breadth wouldn’t exist without Observable, because there wouldn’t be enough manpower to write it. Observable makes it possible for the authors to focus on details without having to recreate the same boilerplate over and over again.
Yes, that attention to detail might mean that the “Getting Started” parts might suffer, but those are usually covered by 3rd party authors and sources (as is the case for many other software projects).

That is an excellent idea! Observable won’t go away, but that doesn’t prevent people from porting D3 documentation from Observable to vanilla JS or write their own tutorials.


If anyone wants to continue this debate, please try to bring some constructive criticism that considers the current reality:

  1. The documentation stays on Observable.
  2. The examples demonstrate concepts, not copy-pastable code.
  3. There is no manpower to make big changes happen.
  4. D3 isn’t a democratic project where you get a say just because you have internet access.
  5. Everything is changing, always, and noone will be spoonfeeding you the updates. You have to put in effort to stay current. Yes, that means reading.
  6. You, too, can make things happen - on your own time.

If you still have suggestions on how to lower the barrier by enhancing the current documentation, go for it! :+1:

8 Likes

Look at the Help section, it’s filled with issues related to Observables. If it really helped authors focus, you’d think the topics in the help section would vary. There’s almost nothing on d3. How can you claim it helps authors focus when you got topics like “How to beautify a code in notebook cells” or “how to set the background color of a cell”. It obviously has the adverse effect. Instead of focusing on d3, people are wasting time on trivial stuff.

2 Likes

I’m talking about the authors of the D3 documentation, @mbostock and @Fil.

You’re conflating D3 and Observable. ObservableHQ is a platform (and service). This forum focuses on ObservableHQ, not D3. The primary help channels for D3.js are listed on its website, namely Slack and Stackoverflow.

Like complaining about the documentation format, you mean?

1 Like

Maybe an Observable notebook from the D3 team that lists resources for using D3 outside Observable, sorted by version/date of publication? (Amelia Wattenberger’s tutorials come to mind.) People can suggest additional material via comments in said notebook or in forum posts.

And if the notebook’s featured prominently enough on Observable (e.g. as part of the “Learn D3” collection), I can see it being helpful to Observable folks who are struggling to migrate outside. I know I’ll benefit from it!

2 Likes

@duynguyen1678 - I think this is a great idea!

Since joining the Observable community, I have learned about many valuable resources such as Amelia Wattenberger’s tutorials (thanks community meetup!) and D3 in Depth—resources which somehow didn’t find quickly when searching Google. Since the Internet is filled with D3 examples (some good and bad), having a collection (or collection within a collection) of Observable-curated tutorials focusing on ‘standard JS’ approaches to D3 would be very helpful.

I also would like to acknowledge that it is a bit jarring to be re-directed to Observable for D3.js examples (as opposed to when this used to be bl.ocks). If I were trying to learn, say, vega lite but to do so required me to learn React.js, I would be more reluctant to try it, since doing so would require me to first learn an intermediary abstraction layer that I don’t commonly use. From my reading of this forum, this is the main issues that folks are flagging. I don’t have a particular ‘solution’ to offer in that respect, but maybe some sort of explanation on the D3.js website would help.

Also, it’s only through this thread that I was alerted to this helpful fact:

All the blocks with D3 examples still exist as gists. If you find yourself trying to look at a block but being redirected to an Observable notebook, you can replace bl.ocks.org with gist.github.com in the example’s url. Then you can clone or download the gist and open it up locally.

Again, perhaps a note on either / both the D3.js and bl.ocks websites would be helpful to people… though admittedly it’s sorta weird to direct people to code examples that are depreciated…

Thank you, everyone, for this discussion!

2 Likes

Coming to this discussion a bit late it seems but I’ve learned so much reading these replies. Most importantly I’m glad I’m not the only one banging her head against the Observable wall!

I’m an academic in computer science. I specialise in data visualisation and I’ve been using D3.js heavily both in research and teaching. I do not understand Observable. I’m sure it’s even greater than bl.ocks (which are amazing btw!) and it seems like a brilliant educational tool, but there’s a learning curve and with a workload like mine (and the people in my research team), I expect that we’ll take quite some time to grasp it. In the meantime, we rely heavily on bl.ocks and the thought of them disappearing was giving us nightmares! good to hear they’re accessible via gist so thanks to everyone who pointed this out!

As to why I am writing a reply, I’m hoping to hear from the Observable team about their UX / HCI design philosophy, as this is an interesting case study for my classes to discuss. As the PACT framework nicely outlines (and usability / UX literature emphasizes) everything starts and ends with “user tasks”. Designing new technology is great but how deeply and thoroughly the design captures what users are aiming to achieve in the real world (regardless of the technology) defines how well a design “matches the real world” (see Nielsen’s usability heuristics).

Judging by the sentiment in this thread, there seems to be a bit of a disconnect between what tasks some of us users expect of Observable and ones that are actually targeted and delivered by the design team. I guess my question is: are the tasks and corresponding requirements satisfied by Observable documented / visualised somewhere? perhaps if we see a mapping of identified user goals and tasks (ideally with some rationale behind them) --> to functionalities + steps that we need to perform in order to unlock those functionalities, we may feel a little better oriented and a little less frustrated. Some useful links have been shared in this thread but the information seems rather scattered. A one-stop-shop mapping would be fantastic to have.

4 Likes

I’m not from the Observable team, but…

I expect that we’ll take quite some time to grasp it.

This is perhaps true for mastery, but I think you are selling yourself short / overestimating the difficulty of getting up to speed with the basics. There is really only one key feature distinguishing notebook cells from ordinary blobs of Javascript code, and that is that the platform constructs a dependency graph and then re-runs a cell whenever there is a change upstream. The trickiest part to figure out might be how “views” work, but there are lots of good examples put out by Mike and Jeremy and I don’t think it will take you inordinately much trouble to get the hang of it.

The other part that might be tricky is that the Observable platform makes it more pleasant and convenient to use “new” (i.e. from the past 5–10 years), “advanced” Javascript features which are not as much used in most JS projects. (Many notebooks are more or less the authors’ personal experiments.) But this kind of learning is not really specific to the platform.

Finally there are details of the editor and website UI, and so on, that take some amount of learning. I don’t think these are each too big a challenge, but fluency comes with experience.

Judging by the sentiment in this thread, there seems to be a bit of a disconnect between what tasks some of us users expect of Observable

I don’t think the folks complaining expect anything of Observable per se, but are more having a problem with having D3 documentation hosted on an unfamiliar platform which cannot be trivially copy/pasted into their own outside project.

In my view the questions are: (1) is being able to copy/paste a whole example into an arbitrary context the most important purpose of documentation, (2) is documentation that doesn’t work that way inherently unacceptable no matter what other kinds of advantages it might have, (3) should D3 users be entitled to demand that all future documentation work exactly the same way as what they were used to previously even if it takes much more work for documentation authors/maintainers?


To end more constructively:

(1) There is a tension when making notebooks between putting more components / variables in separate cells (where they are easier to modify and examine and play with, apply graphical UIs to, and so on) vs. containing a whole graphic or other object in a little package in a single cell where it can be edited as one piece without altering anything else in the notebook. It’s not always obvious what choice to make in the context of a larger work, and refactoring from one style to the other can be a bit inconvenient.

(2) There is a similar tension between relying on libraries or imported notebooks vs. reimplementing everything in a single notebook. The latter is more self contained and makes the code easier to get to, but the former makes it easier to put bug fixes in a single place, etc. Again it can be inconvenient to migrate from one style to the other. In the most extreme example, I sometimes hesitate to import D3 itself into notebooks because it is much harder to patch specific parts of an imported library which hides its implementation behind a shiny API than if I reimplement the parts I need in-notebook.

(3) There is a tension between putting logic directly into an output cell vs. putting logic into a generic function, and then calling it with specific parameters to render a cell. The former makes it much easier to copy/paste the cell and then modify it in place, but the latter enables a change in one place to more easily apply to a large number of cells.

It takes some practice to get a feel for how to make these kinds of standard software engineering code-organization choices whether in Observable or any other context, and for someone indecisive like myself it can be an obstacle to think about it. It’s certainly possible that some better refactoring tools could make this easier, but I don’t have any particular insights about how those should work.

I try to let the intended narrative flow of the document drive these choices, erring just a little on the side of giving readers more knobs to twiddle. Some notebooks have a single tiny graphic as output, and others are closer in flavor to a book chapter. In the former an author might make every little piece into a separate cell, and in the latter the focus is on the higher-level story, so a thousand small cells become a distraction.

But there is also an authoring speed trade-off between quick-and-dirty-hack vs. carefully architected software library. Etc.

3 Likes

It seems like people trying to learn D3 multiple times, but never really getting it, is a common theme (it’s what happened to me as well). I don’t think the amount or quality of the documentation is the issue; if anything there’s so much good material that it’s just all kind of overwhelming. The issue is probably that there are lots of things to get confused about along the way, and it doesn’t help as much to have really experienced people explain it, because they might lack the perspective of someone who is in the position of the confused person. People learning might have sketchy knowledge of any number of issues, like Javascript basics, ES6 syntax differences from old Javascript, basic D3 concepts, differences between D3 versions, what is Observable, what problems is it trying to address, how is it different from just putting Javascript in a script tag…

Just to give an idea of what helped me out: coming across a wall of amazing d3 examples a while ago, and then kind of looking at the code, I just had no clue how I might even start doing anything. That of course leads to the copy and paste mode that a lot of people end up in. The resource that actually helped with this is that old book Interactive Data Visualization for the Web. The key parts of why that book is helpful? It’s SHORT. It doesn’t seem daunting to read the whole thing. It’s INCREMENTAL. It doesn’t dump the whole wall on you from the outset. I get the sense that some of the interactions in the Observable community have the vibe of a PHD person explaining topics to first-year undergrads who don’t have all the background under their belt yet.

Another resource that helped me immensely in learning Javascript was Dan Shiffman’s youtube channel (I think it’s now called Coding Train). Why? When he was starting, he would live-stream himself MAKING EVERY MISTAKE ALONG THE WAY, and then with the help of people in the chat, FIGURING OUT WHAT WENT WRONG. He is certainly wonderfully capable and proficient at what he does, as one of the authors of the p5 library, but this live progression of seeing someone be confused, and then getting unconfused, I think this is what’s sorely missing for D3. I think they covered D3 in one of their episodes (I haven’t kept up with the channel as much recently), but more of that style of, of some non-expert bungling their way through is what tends to actually help.

I get what Observable is doing; if anyone has knowledge of VFX, it’s the equivalent of the difference between Houdini and other 3D programs, or Nuke vs a more timeline based program like After Effects. We certainly want “photoreal” for data science, and scientific computing, and whatever other fields, and these lispy dependency graphs are the way to get there. But I think in some cases, the documentation as it stands might be kind of speaking about solving problems that some people haven’t had yet (or may never have), and you have to walk them through the “wrong” directions (or at least provide some compelling demonstration of WHEN and WHERE that direction might not be such a good idea) rather than just showing them awesome stuff and expecting them to just get it. In my terms, Houdini and Nuke (in addition to addressing key interface issues in their respective domains) address problems of scaling up large, geographically distributed pipelines, and wonderfully solve a whole host of issues that you otherwise collapse from. But trying to explain that to someone who’s just getting going in 3D, or an individual or small studio who just wants to model some stuff in Maya or Blender is bound to lead to all manner of confusion.

I don’t know if you have some documentation person who could do that sort of thing, like Here’s some task that some person coming across D3 might try to do, ok now let’s try it out and see what goes wrong. A series of videos like that would be really helpful.

7 Likes

Hi,
One more question, I just want to know, is there any way or tutorial to change the observable to vanilla, some guide is also welcome, thanks.

I think Observable is great but there is also a learning curve as people have expressed since it doesn’t match popular coding tools like sandbox or VScode. I might suggest something like vizhub.com for beginners who want to work in d3 and/or react!

Here’s an example:
From this notebook Let’s Make a Bar Chart, Part 1: https://observablehq.com/@d3/lets-make-a-bar-chart

Maybe you want to turn the Coding a Chart part into plain HTML document. If you copy-paste this HTML-looking part into an HTML document, it works:

<div style="font: 10px sans-serif; text-align: right; color: white;">
  <div style="background: steelblue; padding: 3px; margin: 1px; width: 40px;">4</div>
  <div style="background: steelblue; padding: 3px; margin: 1px; width: 80px;">8</div>
  <div style="background: steelblue; padding: 3px; margin: 1px; width: 150px;">15</div>
  <div style="background: steelblue; padding: 3px; margin: 1px; width: 160px;">16</div>
  <div style="background: steelblue; padding: 3px; margin: 1px; width: 230px;">23</div>
  <div style="background: steelblue; padding: 3px; margin: 1px; width: 420px;">42</div>
</div>

But then if you copy-paste this next part in a script tag with d3 on the page, it doesn’t work:

<script src="https://unpkg.com/d3"></script>
<script>
  const div = d3.create("div")
      .style("font", "10px sans-serif")
      .style("text-align", "right")
      .style("color", "white");

  div.selectAll("div")
    .data(data)
    .join("div")
      .style("background", "steelblue")
      .style("padding", "3px")
      .style("margin", "1px")
      .style("width", d => `${d * 10}px`)
      .text(d => d);

  return div.node();
</script>

The first thing that goes wrong is that it’s no longer a function, so the return doesn’t work, so you have to comment that line out:

//  return div.node();

But if it doesn’t return the div, then… where’s it going to put the div? So now, if you didn’t know d3 from before, you would be all confused. So, you have to go search for some pre-Observable thing to tell you that what you have to do is select the body of the document, and add the div to it:

//change this part
div.selectAll("div")
    .data(data)
    .join("div")
    ...

//to this
d3.select('body')
    .selectAll('div')
    .data(data)
    .join("div")

Then, it doesn’t know what data is, cause that’s in a different cell. So you can go find data, and copy-paste that in:

data = [4, 8, 15, 16, 23, 42]

const div = d3.create("div")
      .style("font", "10px sans-serif")
      .style("text-align", "right")
      .style("color", "white");

d3.select('body')
	.selectAll('div')
    .data(data)
    .join("div")
      .style("background", "steelblue")
      .style("padding", "3px")
      .style("margin", "1px")
      .style("width", d => `${d * 10}px`)
      .text(d => d);

//   return div.node();

It works even without putting var/let/const/whatever else cause it just makes it a global variable (…when you’re in regular Javascript browser world, that is. But… in the video on the Observable site, it says that that variable name is different, cause it’s a tag for the Observable run-time rather than a Javascript variable, or something like that, right? Yeah, it’s pretty confusing…)

Now it almost works, but your javascript doesn’t know where to put it. Well that’s cause I’m a cheapo and left out all the HTML except the script tag. So if you put the HTML tag at the top, then it works:

<html></html>

<script src="https://unpkg.com/d3"></script>
<script>
data = [4, 8, 15, 16, 23, 42]

const div = d3.create("div")
      .style("font", "10px sans-serif")
      .style("text-align", "right")
      .style("color", "white");

d3.select('body')
	.selectAll('div')
    .data(data)
    .join("div")
      .style("background", "steelblue")
      .style("padding", "3px")
      .style("margin", "1px")
      .style("width", d => `${d * 10}px`)
      .text(d => d);

//   return div.node();
</script>

TA-DA!!!

2 Likes

I want to thank the entire Observable / d3.js team for creating such a beautiful package and platform.

That said, I also struggle with some elements of Observable, so I hope to offer some constructive criticism + solutions – many echoed or articulated better by those above.

Below are a couple problems and some thoughts on how they could be approached differently from a product perspective.

I wanted to capture these thoughts as someone new to the platform, but that also means I may make some silly assumptions or suggest solutions you’ve already thought of and dismissed.

If I did this, I apologize in advance.

Problem I: How can I find examples of D3.js charts that are relevant to the D3 version / JS package I’m trying to learn?

User Notes: I taught myself D3.js v4 mostly from Bl.ocks and 3rd party teachers. One of my biggest v4 breakthroughs was finding Yan Holt’s helpful website which had multiple examples per chart type with varying levels of features & interactivity (ex: tool tips, updating, animating graph / axis transitions between data).

As a beginner, it gave me consistent templates to try out new techniques or chart types to push out of my comfort zone at my own pace.

I sought to re-create a library of snippets from Observable to learn v6, but unless I’m missing something obvious it’s not simple to identify which charts are v6 – or even find the right chart type using the in-built Observable search alone.

Example: Searching for these terms in the ObvHQ search bar didn’t yield the matches I’d hoped (again, maybe I’m missing something)

“pie chart version 6” – 34 notebooks, only 6 pie charts, only 3 using some version of D3, no MBostock
“pie chart v6” – 3 examples, 2 pie charts both DC.js, no MBostock
“pie chart d3.js v6” – 1 notebook, helpful info but not a dedicated pie chart notebook

This may be each authors’ (or this searcher’s) fault more than Observable’s, but improvements are possible

Potential Solution: Introduce Tagging in Notebooks by Author (or Suggested by Community Members)

I know you guys don’t have a lot of man-power, but I think your notebook search (+ potentially external SE results) would be more accurate if you could allow authors to tag their notebooks with relevant info along these lines:

  • Chart Type: Allow them to tag notebook as containing a “Pie”, “Bar”, “Sankey”, etc. or user defined descriptor.

  • Data Type: Allow them to tag notebook as specifically being fed by “CSV”, “JSON”, “TSV”, “Streaming” data. Yes, it’s not difficult to change this (if you already know d3), but it will speed up the process for people looking to learn by example or find a specific solution and expand.

  • Field of Study: Allow them to tag data by their field of focus. I think you might find this more of a community builder than anything.

  • Packages/Version: Allow them to tag whether they are using a specific version of d3.js (and see this easily on page) or package beyond / including d3.js. Something like this is indispensable to someone trying to expand their data visualization knowledge base. Exporting a .tgz to check this is time consuming.

  • Difficulty: This is super subjective so probably the silliest tag suggestion, but at least highlighting the simplest examples by version could help new users immensely. Other users looking for a technical challenge might enjoy the reverse.

After implementation, if I searched for “pie chart v6” it would grab results tagged Chart Type “Pie” AND Version “d3.js v6” and pull those to the top of the result queue.

Tag text would show up colorized at the bottom of each notebook, and users could click the tag to trigger a search page for other notebooks with the same tag.

Community members could also suggest or vote on new tags to be accepted by the author (ideally) or ObvHQ admin (far from ideal) or need to get a certain # of community votes to get added to the notebook automatically.

Further Notes: Please realize that Observable’s SEO is competing with other 3rd party d3 tutorial resources, especially for d3 V5 & 6 and in most cases winning.

So when community members say that those who are interested in learning non-ObvHQ can turn to 3rd party, know that sometimes easier said than done.

Most searches just lead back to Observable examples – which is partially why certain people are unreasonably exasperated about getting vanilla code.

Yes, you do have a lovely list of other tutorial resources on the D3 site, but it’s similarly unorganized by version or skill level with many being v4 or earlier.

Problem II: Observable code format doesn’t always make sense to beginners / non-notebook users on the first pass

User Notes: People coming to ObservableHQ expecting Bl.ocks-like code readability are disappointed at best, completely confused at worst. The reasons why have been well articulated in other posts.

When I read code examples for the first time, as a beginner, ironically, I look for things I DO understand before focusing on the things I don’t. If I don’t understand more than 40% of the code, I get intimidated and look for simpler examples.

On my first visit to Observable, I loved the simplicity and visualizations, but I didn’t understand the order of the cells. At all. It felt like I was reading something written in shorthand and backwards. Shamefully, I didn’t take the half an hour to learn Observable and why this was, I just left.

Potential Solution: Optional Categorization of Observable Cells

I love the elegance of Observables’ cells, but when I compare it to something with high adoption like CodePen, I wonder if this simplicity seeds more confusion in new learners and wonder if a few simple changes to the cells could help with this.

What if when you opened a new cell, it gave you the OPTION to declare what you were going to do with it – HTML, JS, Markdown, Data, Import, etc.

The cells can already obviously do all these things and more, but the fact you’re contextualizing (and maybe even injecting the appropriate markdown for the uninitiated) could make it less abstract, more understandable (compared to other non-notebook environments), and less intimidating.

Categorized cells could show up with a different tint or symbol by type or small title in the corner – and this could be toggled “OFF” by viewer / author and only show on click.

The feature would be like training wheels – unnecessary for experts, but essential for those learning / making examples for beginners.

Further Notes: If something like this were adopted, future improvements could also give users the ability to re-sort their notebook by Cell Type in a way that might be more consistent to them – and provide a skeletal structure for best practices in transferring to / from other environments.
Another potential feature would be detecting packages in the “Import” labelled cells for the first solution described. Just food for thought.

1 Like

I whole heartedly agree and I too avoid using Observable for this very reason.

1 Like

I want to thank everyone for taking the time to participate in this discussion, whether articulating the source of their frustrations, returning to share new knowledge gained or contributing solutions and perspectives.

We are now closing this thread for further discussion.

The thread has become very long and deserves both a summary and an official response. I hope that the following adds clarity and contributes to productive discussion in future (more specific) threads.

As both an Observable employee and as a long-time member and organizer of the D3 community I’d like to reflect on what I’ve heard from this thread and share some official responses.

First, I want to begin by answering the original question, it is ok. D3 is a lot to learn, it has a huge surface area, it already requires you to learn JavaScript as well as browser standard technologies like DOM and networking. D3 also has a large global community with many generous contributors sharing their knowledge and experience for almost 10 years, so if you’re new to data visualization development you aren’t alone.


Clarifying the relationship between D3 and Observable

A number of concerns seem to stem from the way people arrive at Observable, namely being redirected from a google search or d3 block and landing in a new and unfamiliar environment. Here are a few statements I’ve extracted from the various posts:

  • I go to the official D3js webpage, it points me to observable. No where is it clear that Observable and D3js are in fact completely separate entitites
  • I am not given any alternative when I come here from the d3 site
  • I would like to have a usable and up-to-date documentation of the visualization library I use
  • I want to know if I can make a basic plot inside my web application, and how much work it will take to get there
  • all of d3 documentation is in Observable

It is true that there is no clear map of what D3 is and where you can go to learn about it. It is also true that all of D3’s API documentation lives on GitHub, that there are dozens of books and hundreds of tutorials written by community members outside of Observable.

As part of my job at Observable I’m helping to organize a community-lead effort to map out all of the resources for learning D3 culminating in a redesign of the d3js.org homepage. The community and it’s learning resources have grown up organically around the library over the years, with many mature sub-communities. For example as React, Vue and Svelte have grown in popularity people have made numerous tutorials, books and examples around integrating them with D3. As we’ve heard here, people come from all kinds of backgrounds to D3, with all kinds of different goals. Creating a comprehensive map to guide people to where they want to go will hopefully alleviate a large amount of the frustration for those new to the space.


Clarifying the future of official D3 examples

Closely related to documentation and learning resources are the D3 examples, and they demand special consideration.

There are over 400 official D3 examples maintained largely by Mike Bostock and Philippe Rivière. There are also 40,000+ blocks created and shared by the D3 community over the last 10 years. In more ways than one, Mike has lead by example and the community has followed. This brings us to a question raised numerous times in this thread:

  • Why can’t I have the old blocks & new examples to reference and compare?

The answer is simple: it takes too much work. Mike’s vision for Observable comes in part from almost a decade of making data visualization examples! As someone who’s tried to make it easier to make examples, I can wholeheartedly say that Observable is a better way to do it. We will absolutely not stop anyone from translating or making examples elsewhere, however we want to make it clear that bl.ocks.org will continue in maintenance mode but will not be updated.


Clarifying how to use work done on Observable outside Observable

Another common desire expressed in this thread is some variation of:

  • I want to copy paste code out of Observable but its hard / tedious / confusing

Copy-pasting code can mean very different things in different situations. I believe the source of frustration for many here is the desire to bring unfamiliar code into a familiar environment and tinker with it there. To that end, several community members have provided tutorials and examples for doing just that:

As others have pointed out, Observable is actually designed to help you understand the concepts and techniques central to working and thinking with data. We admittedly have some ground to cover to flatten the learning curve even further, and it is at the core of our team’s focus to do so. Since this thread started we have published new Tutorials and Documentation to help with everything from starting out with Observable to embedding or exporting your work into other environments.

Conclusion

I hope these responses give some clarity around the ways both the D3 community and Observable as a team plan to improve the overall data visualization ecosystem. It’s very encouraging to see the contributions from everyone here and I hope you’ll reach out to me with any further concerns.

15 Likes