Since I need it for my InfoVis course! The new one really does not seem very polished in terms of features, visual handles and interactions.
Best
PR
Since I need it for my InfoVis course! The new one really does not seem very polished in terms of features, visual handles and interactions.
Best
PR
We havenāt yet committed to an explicit timeline for how long Old Observable will be maintained; it will depend in part on user feedback and actual usage. But we do have limited resources so we will not be able to run it indefinitely.
Can you please share more feedback on what you are looking for in terms of features and visual polish? (I replied to your other thread.) Thank you!
I needed some time to compile this list, but here are preliminary thoughts as to why Notebook 2.0 feels unpolished:
I use Observable Notebook for many years now, almost daily. I use it in an information visualization course to teach students in a lab class to āvisualizeā and that also for preparing them to create diagrams for their bachelorās or masterās thesis. I also use it for processing my raw results from user studies I do, and I also create the diagrams and figures for my publications.
The old Observable Notebook provided a quite professional data analytics workflow for putting in some raw data (CSV or some other file format) and immediately overseeing the results of user tests in the data table widget, adding programmatically columns out of the raw data columns (simply done in the data table), and then visualizing that newly processed data. So now the data table is gone, which I considered to be the most crucial feature in a workflow besides the plots themselves.
Apart from that, I came across a lot of small glitches that were quite irritating when trying to convert an old notebook into a new notebook.
The left cell border is now too thin. One has to really focus to aim at it to edit a cell.
It had a nice menu for downloading individual cells for further processing and exporting it.
Also, the choice for the type of cell (as with pin/hidden) was left as well. Now, one has to cross with the mouse to the opposite side of the screen. Why? That is an affordance that is not necessary.
The + sign for adding something above and below was already revealed once one hovered over the left cell border. Now, when hovering over a cell border, the + sign is not shown anymore. One has to know that they are there and where they are to reveal them again. Another affordance.
Default cell type: Since I do JavaScript and not TypeScript, I have to go with the mouse cursor to the right side of the cell to change the type every time I create a new cell. Previously that could be done in the same screen area on the left side immediately after one had created a cell. Way faster. With md and HTML cells, itās the same. All cell-related settings and features should be on one side only.
Choosing a cell type often only works when it is done a second time, for example, when converting existing cells from OJS into JS.
When changing code in a cell at the bottom of the notebook that affects a cell somewhere else and it results in an error, the notebook jumps to a different place, but not really to the affected cell.
In general (that also occurs in the old one but the new one even more), these points above create a lot of flicker effects when operating on a page. Especially when some of the cells have a bigger size. The easy solution would simply have the left border visible all the time; it provides orientation and tells you upfront what is possible at which part of the notebook. That gives novices trust because they can explore features at one place/side rather than working on a ājust have to know the featuresā basis
This is great feedback, thank you!
Though the cell border appears thin, the entire left margin of the page is clickable; in effect these are āinfinitely largeā click targets, similar to the menu bar in macOS.
That said, you only benefit from these larger targets once the window is wider than about 1100px. In Old Observable, notebook content was limited to 928px wide when the window is between 1024px and 1440px, at which point is could grow up to 1152px. In New Observable, the notebook is always āfull bleedā to allow for theming (such as a background color), while the content is allowed to grow up to 992px wide. So in the range 1024pxā1120px, New Observable reserves less space for the left margin⦠but we could fix that by adding a breakpoint and taking away space from the notebook.
What window width are you typically using? Would you prefer a larger margin in all cases, or to just make the notebook narrower in the 1024pxā1120px range? Or would you want the margin to āstealā clicks from the notebook content? (I think that would be frustrating but is arguably necessary on very narrow screens such as phones.)
You can open the Export menu by focusing or selecting a cell and then clicking the download icon in the notebook toolbar. This new approach allows you to download from multiple cells at once, and consolidates the controls in a single, stable place rather than throughout the notebook, which is intended to reduce the flickering and movement. That said, you have to be in edit/tinker mode; more on this below.
Iād like to improve this, likely with a mode menu in the notebook toolbar, and perhaps showing something when a cell is empty (as weāve done before)⦠That said, keyboard shortcuts are really the best way to set the cell mode as they are much faster than the mouse (though less discoverable). Command-Enter inserts TypeScript, while Option-Enter splits a cell, preserving its mode. The keyboard shortcuts also work in cell selection mode (Esc, J, K, Enter). And you can insert above using the Shift modifier. And when a cell is empty, Up and Down cycle through cell modes. In Observable Desktop, Command-1, Command-2, etc. also change the mode of the current cell, and these work even when the cell is not empty; unfortunately these shortcuts arenāt available in browsers because they are used to focus tabs; Iād like to introduce some alternatives. And to improve the discoverability of these controls more generally.
Can you explain more why you prefer JavaScript to TypeScript? Are you using Observable JavaScript or vanilla JavaScript? TypeScript is a superset of vanilla JavaScript so there should be no reason to use vanilla JavaScript (unless you want to demonstrate a syntax error). We might also have a user setting to change the default cell mode, though in general we prefer to have the ārightā default rather than exposing many settings.
Not sure I understand⦠is the mode menu not working for you? A video would be great so I can see whatās happening.
This has always been true of notebooks by nature and unfortunately there is not much that we can do. We use scroll anchoring to try to mitigate these changes, but it doesnāt always work. If you have a video or reproduction, or see that this is worse in New Observable, Iāll investigate further to see if we can do anything.
New Observable introduces a read-only mode for non-authors (and you can enter edit/tinker mode by clicking the pencil button in the bottom-right corner); this allowed us to greatly reduce the distractions of the editor interface while reading notebooks. Correspondingly, weāre increasing the visibility of the editor controls in edit mode (which is why the notebook toolbar is always visible in this mode). Perhaps we havenāt gone far enough! Let me play a bit and think more⦠As I wrote previously, we consolidated the controls to favor bulk operations and make the interface more stable. But I expect we will bring back some controls adjacent to the cells, such as for dragging-and-dropping cells to reorder content, or to (more obviously than Command-clicking the left margin) select cells with the mouse.
Really, thanks for all the feedback. It helps!
I just pushed a change to fix this. Iām not 100% convinced because now thereās slightly less feedback as to whether you are hovering the cell gutter (which will focus a cell) or the cell inserter (which will insert one), but letās try it and see!
@mbostock - I think I might know what pr-ju means here, as I have experienced the same.
Attempts to describe without a screen capture videoā¦
Suppose you have an OJS cell that you wish to convert to TS. If you select the cell type via the right-hand cell type indicator, the pop-up with cell type menu appears and stays active with a pointer-release. If you then select TS from the menu, it closes but the cell type stays often stays OJS. Doing so a second time seems to make the change successfully. I found the only way to reliably make the change every time is never to release the mouse pointer when the menu appears on press, and then drag it to the desired cell type.
Hmm⦠strange⦠I have never seen this, and I canāt reproduce it in either Chrome or Safari. Do the other menu items (Pinned and Hidden) exhibit this same behavior for you? Or is it just the modes?
One possible source of confusion here is that the TypeScript cell does not check types; it only strips them. This is handy for people moving between notebooks and a TypeScript environment, but itās not actually giving you type safety in the notebook. Itās only supporting the syntax, not the language server. So it shouldnāt get in your way by flagging type errors on untyped code, but itās also not giving TypeScript fans everything they probably want.
Like you, Iām usually not trying to write TypeScript in a notebook, and it does feel like a weird little lie to have the cell in ts mode. But if it means more people can paste code into notebooks without immediately hitting errors⦠![]()
Exactly that
Yeah Maybe, it is more kind of a marketing issue then, if the ts cell also accepts all Javascript code. I never used typescript, so one does not know that this is the case.
Is this a future feature? Sorry, I cannot find the pencil at the bottom-right-corner!
Related: What does a .js cell do that a .ts cell cannot? Could the .js cell option be removed entirely? That would focus JS/TS in one place and make it a bit easier for those unfamiliar, to adapt to āall JavaScript and TypeScript goes hereā.
Yes that would be a proper solution, then people would not be in doubt as to whether they can do all their Javascript in the ts cell as well.
Till the end of the year would really help me with the course. For next year Iāll adapt the teaching away from the data table view (sorry I was really relying on to that a lot narratively) maybe using the SQL view or adapt otherwise. Please also excuse the tone of my previous mail.
Sorry - not entirely a time when i can share more, but I am constantly in old observable for features pending in new. i appreciate the intention to de-clutter, but i relied on so many of the āoldā notebook features that simply arenāt available in new. please keep old till there is some path to parity
Which features are most critical for you?
Hi Mike and Team:
Features from old that I love and prioritize (sorry - some of this repeats statements made elsewhere):
I still love comments but I havenāt been using them much recently. I also havenāt been using the helper interactions from the old observable cell menu (quick tables, plots, etc), but I loved them and used to use them regularly (I have mostly been offline in Framework recently).
The gear icon for publishing confused me at first, and it feels duplicative of the gear for settings under user profile (which are the settings I would expect). I preferred the globe and share button next to the fork button - it felt more immediately understandable.
ā¦Oh - if we could improve the time it takes to load notebooks after a period of inactivity, that would also be welcome ![]()
And while I am here, a user feedback story: I have difficulty figuring out how to escape from the chat interface after clicking it open. Clicking outside the chat area, pressing escape, and pressing the chat button again donāt work
THANK YOU! I continue to love Observable and continue to be impressed by all that youāre doing! Thank you for the fantastic product and for helping to make it easier to learn JavaScript and to collaborate on data applications!
Thank you again. I read your feedback previously, but itās always good to hear it restated and to see if anything has changed as youāve had more time to familiarize yourself with the New interface.
Your list aligns well with our priorities and weāre working on most everything as quickly as we can!
I just pushed a change to put the comments section below the notebook rather than relegating it to a side panel. Hopefully that will make it easier to read comments and encourage more conversation (while still avoiding comments intruding into the content of the notebook).
if we could improve the time it takes to load notebooks after a period of inactivity, that would also be welcome
Iāve not heard this or experienced this before⦠when is loading a notebook slow? And what do you mean by āload⦠after a period of inactivityā? And is it all notebooks or only certain (computationally expensive) ones?
I have difficulty figuring out how to escape from the chat interface after clicking it open.
Another user reported this, too; I replied:
The way to exit a chat is the same as exiting a notebook: you choose to go somewhere else.
You can go back to your workspace using the workspace menu, create a new notebook, etc. Perhaps we should add a āback to workspaceā button next to the workspace menu. Itās probably worth the space given how common this action is even though itās redundant with the menu.
I guess itās different expectations around a Chat being ephemeral versus a Notebook being persistent? But in Observable a Chat is a Notebook, and so a Chat is persisted, too. What sort of button are you expecting to exit the Chat? (Or are you talking about the Agent panel in the notebook editor?)
FWIW Wolframās version of this general idea is called a Chatbook / Chat Notebook.
Thank you for your (considerable) time, attention, and responses! Regarding my report of notebooks being slow to load ā when I click into my account (my default is currently a Team account, which is another point of feedback weāve discussed elsewhere), I get this for several seconds:
Granted, I have several thousand notebooks, but in Observable 1.0 they would appear immediately.
Also - Jo mentioned this in his wish list (and I also raised it earlier), but the export feature returning also should have made my top priority list
[Toph already shared that youāre on it].
I finally found the comments section!
I missed it before because it was outside of view and in a location I wasnāt expecting. I still prefer the capacity to comment on a specific cell rather than the notebook as a whole, but I am open to change ā itās great to have the functionality at some level. When Tom, Saneef and I were actively working on our SurveySlate project, we relied very heavily on (cell-specific) comments.
But yeah - overall I am enjoying the new experience and having fun re-discovering Observable Notebooks! I am also getting started with Notebook Kit and expect to have a fun app with a Notebook Kit integration to share soon.
Thank you for all these amazing tools! And thank you for sharing with the community!!