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