diff --git a/paper/export-pdf.ts b/paper/export-pdf.ts index 2a59ff49..79942962 100644 --- a/paper/export-pdf.ts +++ b/paper/export-pdf.ts @@ -31,6 +31,16 @@ data["margin"] = [ content: "Correspondence: [author-email]", }, ]; +data["abstract"] = `\ +The anywidget project provides a specification and toolset for creating +portable web-based widgets for computational notebooks. It defines a standard +for front-end widget code using ECMAScript modules and offers tools for +authoring, distributing, and executing these modules across Jupyter-compatible +platforms (e.g., JupyterLab, Google Colab, VS Code). The project has spurred +the creation of many interactive visualization libraries and has been +integrated into existing ones. The standard has been embraced by other +notebook platforms and web frameworks, extending the reach of interactive +widgets beyond the Jupyter ecosystem.`.trim(); let markdown = raw // Replace markdown images with myst images diff --git a/paper/paper.bib b/paper/paper.bib index 392813e1..d9ff876b 100644 --- a/paper/paper.bib +++ b/paper/paper.bib @@ -10,8 +10,7 @@ @software{JupyterBook } @misc{JupyterBookMyst, - author = {Holdgraf, Chris and - The Executable Books Community}, + author = {Holdgraf, Chris and others}, title = {{Jupyter Book and MyST: A community-led, extensible, modular ecosystem for creating computational narratives}}, @@ -56,7 +55,8 @@ @ARTICLE{EDAssistant year = 2023, address = "New York, NY, USA", keywords = "computational notebooks, code search, software visualization, - Exploratory data analysis" + Exploratory data analysis", + doi={10.1145/3545995} } % The entry below contains non-ASCII chars that could not be converted @@ -108,7 +108,8 @@ @ARTICLE{Zhao2022 month = sep, year = 2022, copyright = "http://creativecommons.org/licenses/by-nc/4.0/", - language = "en" + language = "en", + doi={10.1002/spe.3098} } @INPROCEEDINGS{Wang2023, @@ -146,8 +147,7 @@ @INPROCEEDINGS{Wang2023 address = "New York, NY, USA", keywords = "computational notebooks, data science., human-AI collaboration, natural language processing, slides generation", - location = ", Hamburg, Germany, - " + doi={10.1145/3544548.3580753} } @INPROCEEDINGS{Drosos2020, @@ -182,8 +182,7 @@ @INPROCEEDINGS{Drosos2020 year = 2020, address = "New York, NY, USA", keywords = "computational notebooks, data science, program synthesis", - location = ", Honolulu, HI, - USA, " + doi={10.1145/3313831.3376442} } @INPROCEEDINGS{Li2023, @@ -218,8 +217,7 @@ @INPROCEEDINGS{Li2023 year = 2023, address = "New York, NY, USA", keywords = "computational notebooks, data storytelling, data visualization", - location = ", Hamburg, Germany, - " + doi={10.1145/3544548.3580965} } @INPROCEEDINGS{Jain2022, @@ -256,7 +254,8 @@ @INPROCEEDINGS{Jain2022 month = jul, year = 2022, address = "New York, NY, USA", - location = "Pittsburgh, Pennsylvania" + location = "Pittsburgh, Pennsylvania", + doi={10.1145/3510003.3510203} } @ARTICLE{Wang2022, @@ -287,7 +286,8 @@ @ARTICLE{Wang2022 year = 2022, archivePrefix = "arXiv", primaryClass = "cs.HC", - eprint = "2205.03963" + eprint = "2205.03963", + doi={10.48550/arXiv.2205.03963} } @INPROCEEDINGS{Wang2024, @@ -325,8 +325,7 @@ @INPROCEEDINGS{Wang2024 address = "New York, NY, USA", keywords = "Computational Notebook, Cross-Platform Visualization, Data Science, Design, Interactive Visualization, Systematic Review", - location = " Honolulu HI - USA " + doi={10.1145/3613905.3650848} } @INPROCEEDINGS{Kluyver2016, @@ -352,7 +351,8 @@ @INPROCEEDINGS{Kluyver2016 year = 2016, language = "en", conference = "20th International Conference on Electronic Publishing - (01/01/16)" + (01/01/16)", + doi={10.3233/978-1-61499-649-1-87} } @ARTICLE{Perez2007, @@ -369,7 +369,8 @@ @ARTICLE{Perez2007 volume = 9, number = 3, pages = "21--29", - year = 2007 + year = 2007, + doi={10.1109/MCSE.2007.53} } @ARTICLE{Granger2021, @@ -391,7 +392,8 @@ @ARTICLE{Granger2021 volume = 23, number = 2, pages = "7--14", - year = 2021 + year = 2021, + doi={10.22541/au.161298309.98344404/v3} } @ARTICLE{Heer2024, @@ -423,7 +425,8 @@ @ARTICLE{Heer2024 pages = "436--446", month = jan, year = 2024, - language = "en" + language = "en", + doi={10.1109/TVCG.2023.3327189} } @ARTICLE{Ouyang2019, @@ -437,7 +440,8 @@ @ARTICLE{Ouyang2019 pages = "1199--1200", month = dec, year = 2019, - language = "en" + language = "en", + doi={10.1038/s41592-019-0627-0} } @misc{voila, @@ -456,12 +460,17 @@ @misc{nbconvert note = {Accessed: 2024-06-05} } -@misc{jscatter, - author = {Fritz Lekschas}, - title = {Jupyter Scatter}, +@article{jscatter, + title = {{Jupyter Scatter}: Interactive Exploration of Large-Scale Datasets}, + author = {Fritz Lekschas and Trevor Manz}, + journal = {Journal of Open Source Software}, + publisher = {The Open Journal}, year = {2024}, - url = {https://github.com/flekschas/jupyter-scatter}, - note = {Accessed: 2024-06-05} + volume = {9}, + number = {101}, + pages = {7059}, + doi = {10.21105/joss.07059}, + url = {https://doi.org/10.21105/joss.07059}, } @ARTICLE{gos, @@ -485,7 +494,8 @@ @ARTICLE{gos number = 1, month = jan, year = 2023, - language = "en" + language = "en", + doi={10.1093/bioinformatics/btad050} } @@ -508,7 +518,8 @@ @UNPUBLISHED{vitessce month = oct, year = 2021, keywords = "bioimaging; bioinformatics; data visualization; single-cell; - spatial omics; visualization" + spatial omics; visualization", + doi={10.31219/osf.io/y8thv} } @ARTICLE{viv, @@ -523,7 +534,8 @@ @ARTICLE{viv pages = "515--516", month = may, year = 2022, - language = "en" + language = "en", + doi={10.1038/s41592-022-01482-7} } @misc{lonboard, @@ -574,7 +586,8 @@ @ARTICLE{altair pages = "1057", month = dec, year = 2018, - copyright = "http://creativecommons.org/licenses/by/4.0/" + copyright = "http://creativecommons.org/licenses/by/4.0/", + doi={10.21105/joss.01057} } @misc{scipy, @@ -661,3 +674,20 @@ @misc{ecma section={16.2}, notes="Accessed 2024-06-07" } + +@misc{bokeh, + title = {Bokeh: Python library for interactive visualization}, + author = {{Bokeh Development Team}}, + year = {2018}, + url = {https://bokeh.pydata.org/en/latest/}, + note = {Accessed: 2024-09-23} +} + +@misc{streamlit, + title = {Create a Component}, + author = {{Streamlit}}, + year = {2024}, + url = {https://docs.streamlit.io/develop/concepts/custom-components/create}, + note = {Accessed: 2024-09-23}, + organization = {Snowflake Inc.} +} diff --git a/paper/paper.md b/paper/paper.md index 24eccc9a..a4cd8c60 100644 --- a/paper/paper.md +++ b/paper/paper.md @@ -1,15 +1,5 @@ --- title: 'anywidget: reusable widgets for interactive analysis and visualization in computational notebooks' -abstract: | - The anywidget project provides a specification and toolset for creating - portable web-based widgets for computational notebooks. It defines a standard - for front-end widget code using ECMAScript modules and offers tools for - authoring, distributing, and executing these modules across Jupyter-compatible - platforms (e.g., JupyterLab, Google Colab, VS Code). The project has spurred - the creation of many interactive visualization libraries and has been - integrated into existing ones. The standard has been embraced by other - notebook platforms and web frameworks, extending the reach of interactive - widgets beyond the Jupyter ecosystem. tags: - Computational notebooks - Jupyter @@ -54,11 +44,11 @@ reusable web-based widgets in interactive computing environments code based on the web browser's native module system. Second, it provides tools to author, distribute, and execute these modules across web-based computing platforms. Since its release a year and a half ago, anywidget has steadily -gained adoption. Nearly 70 new widgets have been created or ported to anywidget -and published to the Python Package Index (PyPI), along with many standalone -scripts and notebooks. These tools cover general-purpose visualization -libraries [@jscatter; @Heer2024] as well as notebook integrations for -applications in biology [@gos; @vitessce; @viv; @cev], mapping [@lonboard], +gained adoption. Nearly 100 new widgets have been created or ported to +anywidget and published to the Python Package Index (PyPI), along with many +standalone scripts and notebooks. These tools cover general-purpose +visualization libraries [@jscatter; @Heer2024] as well as notebook integrations +for applications in biology [@gos; @vitessce; @viv; @cev], mapping [@lonboard], astronomy [@ipyaladin], and education [@drawdata]. Anywidget has also been integrated into popular visualization libraries like Altair [@altair], enhancing interactivity in notebooks and deepening user engagement with @@ -69,27 +59,32 @@ visualizations and code. # Statement of need Computational notebooks are the preferred environment for interactive computing -and data analysis. Their popularity has spurred the development of interactive -visual analytics systems that integrate seamlessly within these environments -[@Wang2024]. The Jupyter project [@Kluyver2016; @Perez2007; @Granger2021] has -fostered an ecosystem for writing, executing, and sharing computational -notebooks, including tools for converting them into formats like -books [@JupyterBook; @JupyterBookMyst], presentation slides [@nbconvert; -@Wang2023], and dashboards [@voila]. However, approaches for authoring -interactive notebook visualizations vary widely in features and platform -compatibility [@Wang2024], resulting in diverse yet incompatible systems. -This inconsistency hinders composition and reuse of interactive visualizations -in notebooks, fostering platform-specific, monolithic integrations instead of -reusable, modular components that fit various analysis workflows. - -No authoring approach aligns interactive visualization systems with the broader -notebook ecosystem, except for Jupyter Widgets, which show potential due to -their modularity, wide platform support, and advanced features. However, -the complexity and error-prone nature of authoring custom Jupyter Widgets have -limited their adoption by the visualization community, leading authors to -create or resort to alternative methods. A universal protocol is needed to -simplify authorship and support a distributed collection of pluggable -interactive visualizations across computational notebooks. +and data analysis. These platforms provide an interface where users can write, +execute, and interact with code and data in real-time. Notebooks connect an +interactive front end (typically a web browser) to an external system that runs +the code, combining prose, executable snippets, and media. The widespread +adoption of notebooks has driven the development of tools for integrating +interactive visualizations within these environments [@Wang2024]. The Jupyter +project [@Kluyver2016; @Perez2007; @Granger2021] has become synonymous with +computational notebooks, largely due to its widespread success in fostering an +extensive ecosystem of community tools (e.g., for producing books +[@JupyterBookMyst], presentation slides [@Wang2023], and dashboards (e.g., +[Voilà](https://voila.readthedocs.io))). + +Approaches for authoring interactive visualizations across notebook platforms, +including Jupyter, vary widely [@Wang2024]. This inconsistency has led to +fragmented methods for creating and distributing custom visualizations and +interactive components, hindering the development of a composable solutions. +The Jupyter Widgets system shows potential for aligning interactive +visualization systems with the broader notebook ecosystem. However, the +complexity and error-prone nature of authoring custom widgets has limited their +adoption by the visualization community. Widget development is hindered by the +need to integrate front-end code across diverse environments, fragmented +distribution models, and a cumbersome development experience [@scipy]. +Moreover, Jupyter Widgets are Jupyter-specific, with the widest support limited +to Python kernels, leaving gaps in addressing new and alternative interactive +computing environments. A universal protocol is needed to simplify authorship +and support an ecosystem of pluggable interactive widgets. # Overview @@ -142,8 +137,8 @@ using frameworks (\autoref{fig:afm-and-anywidget}a, bottom). These libraries provide utilities to use idiomatic APIs and constructs to manage widget state and to wrap those constructs into the AFM lifecycle methods used by host platforms. For example, anywidget’s React bridge exposes a React-based -declarative hook `useModelState` for accessing widget state and a function that -converts a React component into an AFM `render` method for export. +declarative hook `useModelState` for accessing widget state and a function to +convert a React component into an AFM export. There are several advantages to supporting frameworks via bridges. First, AFM is more stable and minimal because it is not tied to a third-party library or @@ -179,7 +174,7 @@ Widgets in notebooks, standalone HTML pages, and dashboarding frameworks To make widget development more enjoyable and accessible, the anywidget project offers additional development tools for widget authors. It allows for creating widgets directly within notebooks, enabling them to start as prototypes and -evolve into full packages. To align with modern front-end tools, anywidget also +evolve into full packages. Aligning with modern front-end tools, anywidget also implements hot module replacement (HMR) for live code editing development. HMR dynamically updates widgets without reloading the page or losing state, improving the developer experience and enabling rapid prototyping. To enable @@ -209,9 +204,8 @@ provides opportunities for frameworks and platforms to add more specialized support, making better use of their respective internal state management and reactivity systems. For instance, marimo [@marimo], a new reactive notebook for Python, has adopted AFM as the standard for its third-party plugin API. -Similarly, the developers of the Panel web framework [@panel] are exploring -deeper integration with AFM for better compatibility with their reactive -programming model. +Similarly, the Panel web framework [@panel] supports using AFM to define custom +components. Efforts are underway to support AFM with other compute backends besides Python. For example, anyhtmlwidget [@anyhtmlwidget] brings anywidget concepts to R, @@ -233,19 +227,36 @@ documentation about the project can be found at https://anywidget.dev. # Related work Interactive notebook visualization tools vary widely in features and -compatibility [@Wang2024]. Some tools offer rich features (e.g., -bi-directional communication) but rely on platform-specific APIs, limiting -compatibility [@Zhao2022; @Wang2023; @Drosos2020; @Li2023; @Jain2022]. More -simple approaches provide broader compatibility but lack features which -meaningfully enrich user workflows. For example, using static templates or the -NOVA framework [@Wang2022] offers wide compatibility, as the resulting HTML -displays can be embedded in nearly any web-based notebook platform. However, -this approach supports only client-side applications with one-way -communication, meaning that only the initial visualization state can come from -the notebook, without further updates from other cells. Other approaches, like -ImJoy [@Ouyang2019], offer a more unified architecture for building interactive -visualizations with rich features across multiple platforms. However, it is an -entirely separate computing platform with limited JCP integrations, not a -framework for building reusable, modular visualization components. +compatibility [@Wang2024]. Some tools offer rich features (e.g., bi-directional +communication) but rely on platform-specific APIs, limiting compatibility +[@Zhao2022; @Wang2023; @Drosos2020; @Li2023; @Jain2022]. For example, +frameworks like [Bokeh](https://bokeh.pydata.org/en/latest) and +[Streamlit](https://docs.streamlit.io/develop/concepts/custom-components/create) +enable custom extensions, but these integrations are tied to their specific +frameworks and cannot be reused elsewhere. More simple approaches provide +broader compatibility but lack features which meaningfully enrich user +workflows. For example, using static templates or the NOVA framework +[@Wang2022] offers wide compatibility, as the resulting HTML displays can be +embedded in nearly any web-based notebook platform. However, this approach +supports only client-side applications with one-way communication, meaning that +only the initial visualization state can come from the notebook, without +further updates from other cells. Other approaches, like ImJoy [@Ouyang2019], +offer a more unified architecture for building interactive visualizations with +rich features across multiple platforms. However, it is an entirely separate +computing platform with limited JCP integrations, not a framework for building +reusable, modular visualization components. + +# Acknowledgements + +We thank Talley Lambert for his technical contributions to the anywidget Python +codebase and recognize Jan-Hendrik Müller for his significant community +contributions and advocacy of the project. Our appreciation extends to the +entire anywidget community and the Abdennur and HIDIVE labs for their helpful +discussions. + +# Funding + +TM, NA, and NG acknowledge funding from the National Institutes of Health (UM1 +HG011536, OT2 OD033758, R33 CA263666, R01 HG011773). # References