Teams features

We are trying out the Teams feature in anticipation of using it for distributed development:

  1. One notebook page per JIRA feature ticket
  2. All team members can collaborate / contribute to a feature
  3. Some members may only view, comment
  4. Over time bug fixes and other JIRA tickets will accumulate on a notebook page

To make it work, we would want the following:

  1. Collections for our Team Private pages, visible only to Team members
  2. Notebooks moved to a collection no longer appear in the main Notebooks page
  3. Collections appear in the Notebooks overview page with a way to list the titles in a Collection
  4. Viewing and commenting on Private pages free
  5. Version history viewable
  6. Forking merging (I think current capability is sufficient)
  7. Access from notebook page to import data from a private Github repo
    (all Team members will login to Observable via Github, all members of one Github org)


1 Like

Hi Jay.

As a small update here — we’ve just launched Viewers for Observable Teams.

If you invite someone to your team as a viewer, they can only view, search and comment on your team’s notebooks, not edit them.

And perhaps most importantly, viewers are completely free. Your team can add as many as you like, and perhaps upgrade them to editors later on as you see fit.



Thanks! Definitely will try that out. We are planning to more intensively use Observable.
I expect to send weekly summary of each week’s issues / feature requests just so you know

what kinds of things we are trying to do with your product.


1 Like

I am expecting to make weekly feature requests or comments so that you can follow along with our experience. We now have 10 editors and 2 viewers on our team.

Things we think we want:

  1. Team Private, Team Public, Public
  2. Tab showing all Forked pages
  3. Clone a notebook
  4. Refactoring functions

Team Public

I couldn’t use collections so I made an overview document with links to Team Private pages. If I want readable names I have to publish the pages publicly. Also, people don’t know what’s private and what’s up for editing within the Team. The thought was if a Team page was published to the Team, then they can differentiate WIP from Finished and we can use readable names instead of UUIDs in links.

Tab for Forked Pages

Because of no Public Team page, someone tried for their first action to Fork a page, but then decided that was the wrong thing to do because it appeared to pollute the Team Pages space. Having a separate tab for Forked pages could help, also it could be a way to track active modifications to existing pages.


We start a small feature on a single notebook page, then we add to it until it grows too big. At that point we need to split the page and have an overview page that links to both of them. The simplest I could come up with is to clone with overview: 1) clone the page, 2) make a new page, 3) create links to both pages in the new page. I would then go edit the two pages eliminating the extra cells and can edit the overview page to add description around the split.

Pretty mediocre, but beats doing it all by hand. We will probably attempt doing some of these features as tools to help us along. A deeper approach might be useful if your team can come up with one.


Along these same lines, over time we would want to factor out library functions and so on. Right now it is a tedious cell-by-cell copy then delete process.

We haven’t really started developing anything, but people are getting their feet wet and having reactions to what they see. I am hoping next week to get some people started coding on little prototype functions.


1 Like

Thanks for the detailed feedback, Jay — this sort of thing is extremely helpful for us to hear.

Yesterday I set up a table of Team Tasks, and then a table of Team Members so we could list the time of day they work in local time and have an index of things in progress. The table has a link to a Notebook Page for each Team Member. It was a pain to set up.

It would be nice if there was a flow to do the following:

  1. Create a page template
  2. Clone the page N times
  3. Make a JSON list of the new pages

From there, I could code an index page that references all the of the new pages.


A small update for you, Jay — You can now create private collections for your team … and add any of your notebooks (public, private or shared) to any of your collections (public or private).


1 Like

AWESOME! Just added a page to a team private collection. Will get back to you with feedback after we have worked with it for a few days.

This weeks suggestions:

  1. Collections for Teams: have team icon/name follwed by last editor icon/name at bottom of thumbnail notebook

  2. The collections feature is working well now that I have figured out how to group new work. The checkbox + new collection name dialog is concise and well-suited to the problem. I like that you can’t misspell collection names because you have to use the checkbox.

  3. The biggest problems areas now revolve around locating and organizing notebookes:

    a) Collections are a good step
    b) Maybe Teams should have an “Auto Collection” or “Smart Collection” so you can see all the Notebooks that someone has edited (based on history and most recent edit by that person)
    c) I feel the need for non-editable Notebooks

    • Often forget to Fork before editing someone else’s Notebook
    • Especially happens more on Teams since all seem like your own Notebook
    • Once you start importing, a broken page is bad news
    • Non-editable forces a Fork (just like looking at someone else’s)
    • This is a Teams only feature since individual already works that way
  4. The largest unknown is development process
    a) We think we have to migrate experiments to “Production” Notebooks
    - Use a Fork on a prototype / experiment messy Notebook
    - Then edit away rejected code
    - Mark Notebook as non-editable
    b) We then “Download Code” from Production Notebook
    c) Need to cleanup and reformat in JS files
    d) Produce a compiling IDE style Github JS/HTML/CSS library
    e) Compile, PR, and merge to Github (Features, Version, tagged Master branches)
    f) Production Notebook should be close to Github master eventually

    • Ideally we import from Github to Production Notebook

    g) Any changes require forking/testing/confirmation before update Production
    h) We may have to change our Notebook coding style…
    i) We may have to build code extraction/reformat tools…
    j) to ensure that Github is closer to Notebook format (vars, HTML skeletons)

  5. Eventually I will want something more sophisticated to allow review of 15 devs (on a dev by dev bsis) Notebook changes when I don’t know what edits they’ve made over the last day or two.

1 Like

Newbie alert, so please make allowances! I tried inviting my son, as a viewer, into my one man team, the team settings say his invitation worked, but he can’t see a notebook that I, as owner, can. What have I missed? image|690x387

On returning, all worked fine, so all is well !

1 Like

Been making great Team progress. Now I’m concerned about losing our code. I think this could be a separate line of business for Observable.

  1. Allow the entire set of Notebooks for a Team to be downloaded to a single file
  2. Free level you can save to computer or thumb drive
  3. Paid level:
    a. choose providers AWS, Google, Rackspace, etc
    b. Specify frequency of backup
    c. Provide index / history browsing of backups

The main objective is to store on a separately branded service than Observable itself. I want to know that we’re not solely dependent on the existence of your company (acquisitions, funding) or its service being online (GCP outage). Right now I’m worried that Team members accidentally break or overwrite working code. We can probably recover from history, but bulk backups just seems more comforting.

My biggest worries right now are:

  1. Avoiding breakage for working things
  2. Transferring code to production baselines
  3. Losing all the code (once it’s in GitHub, less of a worry but there’s a gap)

The first point is an issue that Team members can all modify each others pages, and there is little friction to do so. A few features that would be helpful:

  1. Non-editable Notebooks (I am currently making a Production collection)
  2. Require forking and suggestion merge in the process of development
  3. A tool for ad hoc collections: All notebooks which import this notebook, other attribute queries

We are using notebooks for experimentation, feedback, collaboration, and approach selection. Once things are working we want to extract code and generate traditional JS applications. Getting the code out is an unknown at this point but involves sharing, exporting, unsharing, then editing the export. We need to bundle several notebooks together for one REST API, then several others for another, etc. I don’t have guidance on what we need yet. In another week we will be producing a baseline and that should give more insight into the types of transitions/reformatting we need to do.



Another Smart Collections idea: all Notebooks edited by a specific person, within a timeframe. I want to look at the last day or two of contributions from various team members. It would be helpful to click through a collection of changes they’ve made.

I’ve been thinking about the “non-editable” Notebook and discover that it is my own apprehension because it is so easy to edit a document. The friction-free nature is so great it makes a notebook seem ephemeral. Rolling back in history works great, but you have to throw out new changes if you revert.

I finally decided that I would like to Tag specific history versions. I can always go back to them and (hopefully) fork from that point if I need to recover a specific working version. If there was github-like history tagging.


It’s been awhile since I posted. We were heads down coding and getting the full team interacting on Notebooks. I had to back off of doing full development in Notebooks due to several things:

  1. Major user apprehension of not using an editor (as best I can tell). There was a real backlash to using other tools than what people are used to (but they weren’t able to voice it that directly).

  2. A belief that writing code in Notebooks would not port over to “real” baselined code. When developing in Notebooks it is a great feature to be able to name things with variables, to use arrow functions and assign them to variables, and to debug any of these values because you can immediately see and interact with the results based on expectations. That code does not port directly as written because it has to be declared with let or const, and scoped to a block that doesn’t exist on the Notebook page. The arrow functions often are more easily ported via copy and paste if they were written as traditional functions. Since no one on the team had experience before, they didn’t constrain their coding style to make it easy to copy and paste to a different context.

  3. The process I intended was: a) prototype, b) rewrite by forking in a “production” page, c) copy using some tooling we added to paste into a git project with CI/CD or command line build, d) debug by porting back portions of baseline for quick focused iteration. After animated debate, the team decided Notebooks were great for prototyping, but once in Git they weren’t useful anymore and we stick with traditional IDE tooling. Also, the jump from Notebook to Git was painful and they weren’t that willing to do it – so they preferred proof-of-concept then rewrite in IDE.

This is quite misleading from a benefits standpoint, partly caused by tooling gaps, perceived pain, and miscalculation of time spent. Having been through some debugging / UI adjustments, it is 10x faster to pull a small piece into a Notebook and iterate until the annoying glitch is replaced. None of the others seem to want to pull things back into a Notebook, and typically only prototype or POC when they start a new feature. The miscalculation comes in that by living in the IDE it is considered one step rather than X hours, whereas Notebook -> IDE -> Notebook is too many steps even though it is X/2 hours or less. The idea that some rewrite is necessary after something is working is anathema to their existing comfortable IDE process. I can only hope that specific situations with bug fixing or UI adjustment will eventually convince them that there are faster methods than the IDE available.

  1. The organization of and access to Notebooks. This was a big hindrance when we got to 100+ Notebooks and 6+ developers working simultaneously. The recent release of the new Notebook lists, filters, and collections interface is a HUGE first step towards solving this problem. We had more than one instance where a fork of a fork of a fork… ended up getting lost and never found again, so some people had a sense that they might lose their work in the noise and weren’t willing to put much effort into a Notebook.

I still think there should be Smart-Collections, and that users can specify things like All Pages Forked by Me as an example of a Smart Collection that can be created with a combination of the filter tools that now help organize Notebooks.

Maybe general development isn’t the target, and storytelling / data viz / data journalism is the target, but a more seamless integration with Git is essential for a better development experience. We are not delivering or executing Notebooks or the execution environment in production. We are targeting ES6 vanilla JS with d3 and as few other libraries as possible, so maybe rollup at most for build tooling. Even still the belief that rewriting, package reformatting, or general manual code hygiene being necessary was an issue that turned people off. Better ways to export or import parts of a project would make it much easier to incorporate into a development tool chain.

I really love the Notebook listing enhancements, they are essential to Team Development. Thank you for the advances!