Fresh & clean new cell name display

We just shipped a UI change:

Before, cell names extended to the left of the notebook. Now they sit right next to the associated values:

This means a few good things:

  • It’s one more perk for people with narrow or narrow-ish screens: cell names are visible immediately.
  • For readers, this should make the reading experience more comfortable and focused, without being distracted by potentially irrelevant content on the left margin.

We do note that this means that outputs don’t have names by default shown. You can still see the names in the code that generates the cell, and also as the first item under the ⠇ menu.

If you want to label an input and were previously doing so by relying on the cell names, labeling the input in the main content flow is recommended and Jeremy’s inputs notebook is a great way to do so simply.

3 Likes

I tended to use ctrl-f often to locate a cell in a large notebook. Will have to find another way.

Related: Via UX prompt: Ctrl-F to find code in someone's notebook

1 Like

It’s great you want to improve UX and support narrower screens. However, I often relied on cell names, especially for visual output like html, md and viewof. I often work on a 13 inch macbook pro, sometimes with a 28" screen attached to. The only times screen with has been a problem was when I opened the console for debugging. It seems that this could be an optimization for smaller screens using responsive styles instead of broad default.

3 Likes

Sorry if it’s inappropriate to write to this thread, but it seems to be related – What’s the rationale for no longer showing the cell names to the left side of each cell?

1 Like

Thanks for directing me to the correct thread. I am with @denik - I found the left-margin labels especially helpful to see html cells, such as ones where I link in CSS files. Under the new UI, these cells are essentially hidden.

1 Like

One reason we removed the cell names from the left margin is that notebook authors (including myself!) were relying on these names to describe interface components such as sliders, and since the cell names were never visible on small screens, readers would often be confronted with an array of confusing, unlabeled inputs.

By choosing a design that is more consistent across screen sizes, we’re explicitly encouraging authors to label their inputs directly rather than rely on the cell names. (See Jeremy’s inputs, for example.) But it’s not strictly a loss—in the case of inspector cells (e.g., d3 = require("d3")), we can now show the cell names on small screens where we couldn’t before.

The tension here is that we want notebooks to communicate effectively (to be a joy to read), to give authors control over their appearance, and to provide good defaults. Interrupting the main column of content with the cell names in all cases would be distracting, so we have to strike a balance.

4 Likes

Thanks for taking the time to respond, Mike! I’m sure you guys weighed a lot of options before arriving at this but I just wanted to throw in my $0.02.

It looks like the crux of the problem is navigation to cells during development. Intellij has a CMD+OPTION+I (I think) shortcut that pops up a searchable list (alfred/spotlight style) of all global symbols in the current namespace – equivalent to cell names in an observable notebook. Upon search and pressing enter, it navigates scrolls to selected symbol, similar to your ToC notebook. Maybe that’s an idea.

Thanks for the great work!

2 Likes

Me too, so I wrote a short user style to bring them back:

@-moz-document domain("beta.observablehq.com") {
div[id][data-node-id]:before {
  content: attr(id);
  position: absolute;
  right: calc(100% + 20px);
  top: 5px;
  pointer-events: none;
  z-index: 1;
}
}

Screenshot:

8 Likes

YMMV, but I strongly dislike this change. Now the name (of an arbitrary code object, diagram, intentionally named section title or paragraph, etc.) defaults to invisible, whereas before it defaulted to visible.

There is now also no way to distinguish at a glance cells which have anchor links vs. those which don’t.

5 Likes

Observable dropped the “beta.” subdomain, so you might need to update your user style domain:

@-moz-document domain("observablehq.com") {
div[id][data-node-id]:before {
  content: attr(id);
  position: absolute;
  right: calc(100% + 20px);
  top: 5px;
  pointer-events: none;
  z-index: 1;
}
}
1 Like

Does @-moz-document imply that this will only work for Firefox? Would a chrome solution be @-chrome-document? Is there a possibility for a generic script?

I am with limited Internet connectivity again and unable to just try for myself. Apologies for asking without first testing.

I think the @-moz-document is a cross-browser standard for user styles. You might have to install an extension to get it to work though.

2 Likes

Here are the updated styles that work for both classic and next:

@-moz-document url-prefix("https://observablehq.com/") {
  /* classic */  
  main div[id][data-node-id]:before {
    font-family: var(--monospace);
    font-size: 14px !important;
    line-height: 33px;
    vertical-align: baseline;
    content: attr(id);
    position: absolute;
    right: calc(100% + 25px);
    top: 0;
    pointer-events: none;
    z-index: 1;
  }
  /* next */
  #__next .notebook div[id][data-node-id]:before {
    font-family: var(--monospace);
    font-size: 14px;
    line-height: 26px;
    vertical-align: baseline;
    content: attr(id);
    position: absolute;
    right: calc(100% + 60px);
    margin-top: -26px;
    pointer-events: none;
    z-index: 1;
  }
}
4 Likes