I assume they break because something in the code was not asi it should be, but it worked in the old version. Also, with the minimap gone, it´s somewhat hard to try to figure out whats broken and where
Here is one:
https://observablehq.com/@rusosnith/retuits-milei
In the same style, this new selector to change the type of cell seems really out of the user path (and is not apparently clickeable… and you know it, asi it has a “click to change” advice on the tooltip)
In the old notebooks all this controls where in the same area and behaved similary, and now they are spread in different places with odd and unexpected UX?
For this we recommend selecting multiple cells and doing them all at the same time rather than one by one. Using keyboard shortcuts, if you are editing a cell, hit Esc to focus the cell, then hit Shift-K to select the current cell and move up, or Shift-J to select the current cell and move down. Then hit . (Period) to toggle whether the selected cells are pinned, or click the corresponding pin button in the toolbar.
You can also Command-click the left gutter to select cells with the mouse.
We’ve consolidated all the controls into the toolbar rather than repeating the controls separately on each cell. The new design favors bulk actions on multiple cells rather than repeating actions for each cell. And it means the controls don’t move when you move between cells, or appear and disappear (as much) when you hover over different parts of the notebook; the toolbar is always in the same location to improve predictability, and the user interface is more stable.
The mode menu is an exception… It’s nice to see the cell mode in the cell itself because it affects how you read the code. And there isn’t yet a way to change the mode of multiple cells. I’d like to add that soon, as well as some more discoverable ways to select cells, like the checkboxes we have in the old editor.
Anyway, I’m sorry if you dislike the new interface but I thought you might like to know our rationale and I hope the new interface will grow on you after you spend more time with it. Thank you for the feedback!
Your notebook appears to be broken in the new editor because it’s using a data table cell, and since data tables cells aren’t supported in the new editor, we automatically translate data table cells to vanilla JavaScript cells, but the translated code (in this case) isn’t perfectly equivalent.
Specifically, your notebook has a dataLoaded variable and you’re using d3.csvParse to parse it, but this doesn’t do any type interface so you get back an array of objects whose values are all strings. This then breaks the downstream plots.
If you change the code in the dataLoaded cell from
d3.csvParse(text)
to
d3.csvParse(text, d3.autoType)
then you’ll get back typed objects (numbers and dates) which will then render correctly. Previously, the data table cell was doing that implicit type inference for you.
(d3.autoType is fairly limited in its type inference and so isn’t quite as smart as what the data table cell was doing. A more robust approach would be to download the retweets.csv and attach it to your notebook, and then use FileAttachment("retweets.csv").csv({typed: "auto"}) to parse it. We could maybe expose the inferTypes method used internally by FileAttachment so that you could use it here…)
Congratulations on the launch! 
I appreciated the comments on AI.
A tiny thing I noticed reading the official announcement is that cmd+clicking a link doesn’t seem to work in Safari, though it does in Chrome. In Safari, Cmd+Click does nothing while a regular click works as expected. This is with Safari Version 26.6.2 (21624.5.1.11.3) on the latest macOS.
The error shown in the console is this:
Refused to load Things You Should Never Do, Part I – Joel on Software because it does not appear in the frame-src directive of the Content Security Policy.
Thanks for the explanations and the quick turnaround!
We are all in the mood of “yelling at the cloud” because things that were normal just changed, but in our feedback may be hidden some user cases you may not know about.
Thanks for the explanation and the workaround!
As a designer who learned to code back in the blo.cks era, my code definitely isn’t perfect… but I am concerned that many old, unmaintained notebooks (which are still incredibly useful, especially for teaching) will eventually be broken forever by this update. Are there any plans for backwards compatibility to support these cases, such as using “data table cells”?
Regarding your suggestion, d3.autoType often doesn’t work well with non-English formatting standards or poorly structured files, which is why I typically avoid it.
We’re trying very hard to maintain backwards compatibility and be responsible stewards of the platform. Feedback like this helps us to identify where we need to improve backwards compatibility, and we will continue to work on it.
That said, we’re not perfect and we have limited resources, so we can’t guarantee that nothing will break. If you want to further isolate yourself from platform changes (and other external dependencies), you can also self-host notebooks with Notebook Kit.
Thanks for the report, Yuri. We just pushed a fix for command-clicking links in Safari.
Okay, noted. These are your strategic choices. But what will happen to the runtime embeds created with the free version of Observable 1.0? Will they continue to work?
Agreed. The new interface feels excessively minimal - less like a workspace with tools at the ready and more like, well, an expanse of whitespace. Like typeset output instead of a notebook. I know the balance of needs is different for every user but for what it’s worth I found the conspicuous controls on each cell helpful.
@anoved, could you share the top 5 to 10 controls you most miss?
We really miss the search bar or any way of searching for a specific notebook. We have almost 250 Notebooks.
Collections help a bit, but the functionality is limited. The once available tag functionality would help more, since you could combine different tag for subselections an specific filters.
We are also very interessted in the implementation of the embeding functionality, since this is a critical functionality for us.
Thanks for the feedback, @resmartiZH! We’re working on search and embeds and they should be coming soon. I don’t think we’ll reintroduce tags since they are too similar to collections, and also they tended to be used somewhat haphazardly and rarely; tagging places the burden on authors to categorize their work, whereas machines are good at doing it automatically. But we have been toying with the idea of public collections where anyone could contribute their work, maybe with moderators? I don’t want to get distracted by building the computational notebook version of Reddit though, haha.
Yep, that is going to be replaced with the find panel that lives along the side of the notebook and lets you do find and replace across all cells in the notebook. Coming soon (hopefully)!
I like the new interface.
I wish to see customizable code prettier options and a way to set the default new cell type.
Do I need to use JS cells after this, or will OJS cells be supported forever?
Trying to understand how to do an old idiom correctly.
I use Observable for my class. In the old version (week 2 of my class, surprise!), I had students fork a notebook in the Team to do assignments; the fork would just be private to the student until they shared it with me. Now, it appears everything defaults to Team visible which is an issue for assignments for I hope clear reasons.
How do I (can I) have a similar workflow in new Observable?
I’m not sure there’s a solution to this yet. But just to register that I too am after a solution to this use case for my students. I was talking with Toph about this just yesterday, so I hope it is on their radar.
(Also - Hello T.J.!)
