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:
- The documentation stays on Observable.
- The examples demonstrate concepts, not copy-pastable code.
- There is no manpower to make big changes happen.
- D3 isnāt a democratic project where you get a say just because you have internet access.
- 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.
- 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! 
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.
2 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!!!
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.
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:
- Convert observable code to normal Javascript / David B. / Observable
- Observable vs Regular Flavor Javascript / Carlos Sandoval Olascoaga / Observable
- Learning from D3 in Action - in Observable / Tom MacWright / Observable
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.
14 Likes