A Copilot for Notebooks
What would Copilot look like for computational notebooks?
For you skynet users, here is the speed read prompt: design notebooks jupyter-notebook AI assistants copilot-like design-space suggestions{2.} UI-design methodology: interview feedback-analysis trust-of-system control design-features respect-to-user, also, no, this blog aren’t gernerated by these prompts.
Coding assistants using AI such as Github Copilot can provide high-quality suggestions based on the context of given source code or natural language, boosting programmers’ productivity, offering more options to explore, and reducing potential bugs. AI coding assistants work well with integrated development environments (IDEs) such as Microsoft Visual Studio Code. Data scientists, on the other hand, tend to use computational notebooks such as Jupyter Notebook, but these environments are also a form of IDE. In other words, applying AI assistants to computational notebooks should — at least in theory — be a good idea!
Computational notebooks are more like the playground for data scientists. Notebook users often write small snippets and run them interactively to explore, understand, and learn the given data or code. Besides code snippets, notebooks also support a wide variety of media such as data tables, plots, formulas, or documentation in markdown formats. Given these differences, simply adding an assistant designed for pure source code IDES to a notebook may not yield the best outcome for notebook users. Which begs the question: How should we adapt these differences to the design of AI-powered code assistants for notebooks?
This was precisely the question that Andrew McNutt and a small group of colleagues at Microsoft Research had in publishing the paper On the Design of AI-powered Code Assistants for Notebooks at CHI 2023.
Andrew and team first set off by looking into the existing options in the design of AI coding assistants. They wished to gather features from the existing ones as Lego bricks to later build their own AI notebook assistant.
During the search, they went as far as they could to try to build and understand the boundaries of these assistant systems alike instead of just doing a summarization of currently popular patterns. Counting Github Copilot, they analyzed 14 different systems and summarized their features and functions into the following design space diagram:
With the design space settled, Andrew and colleagues then moved to the second part: an interview study. They built different prototypes from the ingredients in the design space. They then recruited 15 people from a large data-driven software company (which may or may not be Microsoft) based on job title and self-identified experience with notebooks and AI code assistants. Most of the people who took part in the interview had a few months of experience with AI code assistants while all of them had years of experience with notebooks or data science and a master’s degree in a computer science-related field. Andrew would set up a video call with each participant and present the prototypes and imaginary tasks, then ask about their experiences and ideas. Later Andrew and his team would discuss and reflect on the recorded interview from time to time until ideas saturated.
Users expect the AI assistant as a ghostwriter to take care of the trival part of their work as copying and pasting necessary stuff from StackOverflow. As the different users will have different views on which part of their work is trivial or not, designs should create different explicit systems (different ghostwriters) for users to switch to, for example, systems for formatting visualizations or dealing with data tables. Such that users can focus more on the parts they find more valuable.
Andrew also made an amazing presentation for this paper, check that out if you want more information!
Paper citation:
- McNutt, A. M., Wang, C., Deline, R. A., & Drucker, S. M. (2023). On the design of AI-powered code assistants for notebooks. In Proceedings of the ACM Conference on Human Factors in Computing Systems (pp. 1–16).
