Since our beta started, Ridge AI’s Build Agent has turned datasets into interactive dashboards. Feedback from customers and many rounds of evals showed us where it fell short of our vision, so we re-engineered it from the ground up.

The hard part is knowing how much to ask before building. Too many questions and it’s a chore, too few and you get a plausible dashboard answering the wrong question. Arrive with a clear brief and the new agent gets straight to work. Start with only a broad goal and it asks focused questions grounded in your data, offering useful directions when you’re not yet sure what matters. Either way, it summarizes its understanding for you to confirm. It can also draw on documents you’ve already written, like metric definitions or business rules, instead of asking you to repeat them.

Once the goal is clear, the agent works in stages: first understand the data and what you’re after, then define the metrics and filters that answer it, and only then design the charts. It turns the confirmed goal into a plan and keeps every requested part in view as it builds. If something needs to be adapted or isn’t supported, it tells you what changed. What each stage learns carries into the next one and into later refinements, so the dashboard stays connected to its original purpose.

Visual analysis is rarely a straight line, of course. The agent can reconsider choices as the dashboard takes shape, and explicit undo and redo let you back up and try another direction. You can also rearrange the dashboard directly and continue working with the agent from there.

Build Agent 2 is live for all beta customers, including existing dashboards. Nothing to migrate or turn on. We have a few more exciting updates going live in the coming days and weeks as we prepare for general availability.

Happy building! 📊 And ping Ellie, Jeff, Andy, Elias, or me if you have thoughts, want beta access, or just want to chat about a cool dashboard of yours.

To help you develop better intuition for high-dimensional datasets, Nezar Abdennur and I built dtour, a visualization tool for smoothly navigating through data projections.

→ https://github.com/flekschas/dtour

Some dimensionality reduction methods find interesting angles but hide everything orthogonal to them. Other methods compress the whole manifold into 2D, which can muddle genuine structure with layout artifacts.

Traversing multiple projections can help build a more holistic understanding of high-dim manifolds, and dtour makes such exploration effortless through one interface: you can switch fluidly between an overview gallery of projection “keyframes”, a guided cyclical tour along geodesic paths connecting keyframes, fine manual axis manipulation for user-driven excursions, and a wandering grand tour for serendipitous discovery.

dtour is built around two types of workflows:

1. revealing structure in a single high-dimensional space through hyperdimensional tours, and
2. validating or comparing embeddings through sequential tours over a series of 2D projections.

For examples:

Dmitri Kobak and colleagues have shown that non-linear neighbor-embedding methods all lie on a spectrum that weighs attractive forces between neighbors against repulsive forces between all points. Smoothly scrubbing along that spectrum on Fashion MNIST makes it tangible which clusters in a UMAP-like layout are genuine signal and which only emerge under strong repulsion. You can also tour through the structure of a single high-dimensional dataset along its own spectral basis. For instance, on a 346K-cell single-cell surface-protein dataset from Florian Mair, a Laplacian Eigenmaps tour recovers known immunological hierarchy and gradually reveals cell phenotypes.

On the validation side, we used dtour to inspect a 2D UMAP using a 8D PCA tour of a 276K-cell developing mouse brain from La Manno et al. showing which clusters are visible in the linear basis and which are exaggerated by the non-linear embedding. You can also use dtour to compare different embedding methods. For instance, a sequential tour through four embeddings of 3 million arXiv title+abstracts under SPECTER2, BGE-M3, Nomic Embed v2, and F2LLM-v2 8B surfaces where modern sentence embedding models agree on similarity and where they don’t.

Explore these yourself: https://dtour.dev

dtour is optimized for performance: it runs smoothly for up to ~10M points and remains usable up to ~20M. To get there, we use WebGPU/GL, Web Workers, and OffscreenCanvas.

dtour runs in any modern browser, ships as a Jupyter/Marimo widget for notebook workflows, and embeds in React apps.

Preprint on arXiv: https://arxiv.org/abs/2605.04306.

And if dtour proves useful in any projection of your reality, please subscribe to a wonderful rest of your day.

It’s been a minute since the last update and quite the journey since 2020. The API has been stable for a while now, and I finally addressed the last remaining things on my list, so it felt like the right moment to cut a v1.0.

→ Code: https://github.com/flekschas/jupyter-scatter → Docs: https://jupyter-scatter.dev

Three things in particular made this version feel ready:

1. Arrow PyCapsule support. Jupyter Scatter now accepts any DataFrame that implements the Arrow PyCapsule interface (Polars, DuckDB, etc.). Thanks Kyle Barron for bringing this to my attention! The integration ended up being super easy thanks to the well-designed protocol.

2. Full Marimo support. The toolbar UI moved from Python ipywidgets to TS+React, which means Jupyter Scatter now also fully works inside Marimo notebooks. 🎉

3. Point draw ordering via order(). Useful when overplotting otherwise hides the points you actually want to see or when you want to move NA/noise points to the back.

Other goodies:

• Categorical color encoding in the histogram bars
• Mostly Python 3.14 support (the one gap is label placement, since geoindex-rs doesn’t have 3.14 wheels yet)
• The usual bunch of bug fixes (mostly around categorical color encoding)

Full changelog: https://github.com/flekschas/jupyter-scatter/blob/main/CHANGELOG.md

Reflecting back, the most critical part of Jupyter Scatter has always been the ease of its API, and the most profound step toward that happened 5 years ago in PR #4 (https://github.com/flekschas/jupyter-scatter/pull/4). Everything since has felt like candy on top. Not a new insight, but worth saying out loud: getting the foundational interface right is what matters most.

Huge shoutout to Trevor Manz for years of continued support, and to Nezar Abdennur for critical feedback at the very beginning that shaped the now-stable API. 🙏

A secondary goal was that Jupyter Scatter would be useful beyond a standalone widget. I.e., that other tools could build on top of it. I’m happy that this has worked out, e.g., in Ozette’s comparative-embedding-visualization (https://github.com/OzetteTech/comparative-embedding-visualization - Let’s gooo Trevor Manz!) and scSketch (https://github.com/colabobio/scsketch - More soon from Askar Temirbek and Andres Colubri 🎉). Hopefully others will follow.

Jupyter Scatter also inspired a new tool that goes beyond the fundamental limitation of single 2D projection scatters… 🫣🤫

Anyway, thanks for reading until the end! If Jupyter Scatter has been useful to you, I’m happy. Keep scatter plotting 💪

Slides: https://speakerdeck.com/flekschas/data-visualization-tools-in-the-age-of-ai

The goal of a visualization tool is to raise the insight rate, i.e., how quickly a user gets from data to a relational understanding. Many academic visualization tools have practical limitations that hinder adoption (think a steep learning curve or missing practical features), which results in a real-world insight rate that’s not significantly above common plotting tools. So how does AI change this picture?

It depends on what you start from. Applying AI to a closed, monolithic tool only goes so far. You might get a friendlier onboarding step or a chat sidebar but that’s it. Applying AI to a tool that’s already integrated, composable, scalable, and programmable yields compounding benefits: shorter learning curves (AI helps explain and use your tool if it’s programmable), almost no tool switching cost (AI can compose and integrate tools through MCP etc.), and a higher insight ceiling (AI can help surface and explain analysis or data collection artifacts not shown in the vis tool).

Hence, AI multiplies what’s already there! A tool’s engineering design principles are critical as they now sets the ceiling on what AI can do with your tool for your user.

I’m curious how others are thinking about this. Where have you seen AI genuinely compound a vis tool’s usability/usefulness, versus mostly sit on top of one?

And again, many thanks Qianwen Wang for the invite!

A few weeks ago I wrote about how AI-native visualization tools need well-engineered constraints. While building the agents, I kept asking: which steps can we constrain to keep things focused and reliable? SQL-only queries instead of free-form code, automatic cross-chart filtering, consistent color encoding: each removes a degree of freedom, and the result is an interactive dashboard in under a minute. Leaving you free to ideate, adjust, and explore.

The payoff is a shift in attention. Instead of thinking primarily about how to visualize your data, you can anchor on your actual goals and questions.

If you’re interested in what we’re building and want to join the closed beta, please reach out.

One thread I keep coming back to: the engineering of constraints around AI-native tools.

There’s broad consensus that AI collapses implementation time. I built dtour (https://dtour.dev) in two days as a working prototype, which would have taken me weeks/months before. But the harder, more interesting question is: what makes the output good rather than generic?

I believe it’s about shaping the solution space. The goal of a visualization tool is to help people gain insights fast. Classic tools often have a deep learning curve before that insight rate goes up (if at all). AI-native tools can lower that curve and offer deeper insights, but only if the tool’s solution space is well-constrained to guide AI. Without constraints, you just get mediocre results faster.

Constraints aren’t just guardrails, they’re architecture. It’s like mentoring an intern. You don’t let them explore aimlessly, but you also don’t dictate every step. You define the problem boundary, set the right level of structure, and let productive exploration happen within it. Over-constrain and the work is predictable. Under-constrain and it’s inefficient. The same holds for AI agents generating data visualizations.

Jeff Heer, Ellie Fields, Andy Caley, and I are trying to put this into practice at Ridge AI: well-scoped declarative specs, automatic interactions, and hard constraints where they matter (like using SQL instead of Python for analytics) to produce useful and trustworthy analytical dashboards as fast as possible. So users can focus on what matters: answering data questions.

The question of what’s the right level of guidance extends to the human in the loop as well. If the tool suggestions are too precise or elaborate, people might rubber-stamp and stop thinking. Too little, and AI feels unproductive. You need the right amount of friction, as Angie Boggust pointed out. I’m curious how other folks approach this balance in their work.

Code: https://github.com/flekschas/mcp-web Docs: https://mcp-web.dev

With MCP-Web, your frontend app becomes the MCP server. AI doesn’t need to parse HTML to identify possible actions. It gets typed tools to directly manipulate your frontend app’s state like your UIs do.

This approach makes the frontend (instead of the database) the main control surface, which has a few benefits. Primarily, it makes human-AI parity straightforward. Humans control state through UIs and AI controls the very same state through MCP tools. So both have the same capabilities. This also enables mixed-initiative interactions: you can automate some tasks with natural language and use pointer interactions for others when you want to.

Try it: https://todo.demo.mcp-web.dev is a todo app that either you or AI can fully control.

Another benefit of making the frontend the main control surface is when your UI has rich ephemeral state that shouldn’t live in a database. Think of dashboards, visualization tools, or visual analytics with crossfilters, selections, and dynamic color scales. Or a 3D viewer with camera and display settings. These view models are often larger than the data model itself. Moreover, if you want AI to show UIs to the user (via MCP apps), the frontend is the natural place to define them as it already renders those UI components in the browser.

A good example is the HiGlass genome browser: https://higlass.demo.mcp-web.dev lets you browse and configure it using any MCP-compatible AI agent.

To build AI-controllable frontend apps with MCP-Web, the main work involves modeling your frontend state declaratively. Break your state into atomic and derived units, and describe it with Zod schemas. Exposing your state as tools is then straightforward. MCP-Web comes with utilities to streamline the automatic generation of token-efficient MCP tools and apps, and is framework agnostic.

MCP-Web also lets you trigger AI queries directly from the frontend. Your app can “ask” AI questions, not just respond to AI requests. As an example, https://checkers.demo.mcp-web.dev is a checkers game where you play against AI. But since the app is AI-controllable, you can also let AI play against AI or have AI explain moves.

If you’re curious about the philosophy and design decisions behind MCP-Web, keep on reading at https://mcp-web.dev/made-with-love.

Why I Created MCP-Web

MCP-Web started out of curiosity. I wanted to know if it’s possible to control visual web-based data interfaces through AI while allowing users to remain in full control and be able to take over at any point.

Visual interfaces, like dashboards or visual analytics apps, are different from other interfaces for two reasons. First, such interfaces often have a rich ephemeral view model to enable exploration. And such models are often much larger than the data model. Think of crossfilters, camera settings, or display configurations. And second, while some interactions are more efficient with natural language, others are better suited for pointer events. E.g., comparing two datasets is faster expressed in natural language while manipulating the camera position to your liking is much faster using a pointer interface.

MCP-Web is the result of me and Claude exploring how to make it as easy as possible to build frontend apps that both humans and AI control equally well.

Human-AI Parity

A core principle that underpins MCP-Web and the design philosophy behind it is to ensure the human user never loses agency while at the same time enabling AI to effectively operate a frontend app. There should be parity between both. Whatever the human can do the AI should be able to do and vice versa.

In the past, graphical end-user software was most often designed purely for humans interacting through screens and pointers. Unlike CLIs and APIs, GUIs were rarely built with programmatic control or integration in mind. You could argue that made sense before working AI existed, but it meant these tools became hard to automate, integrate, and learn.

With modern LLMs, there’s really no reason anymore not to make graphical interfaces fully programmable and AI-controllable. Even when complex UIs are unavoidable — and they can be, trust me, I’ve built many — LLMs allow us to lower the entry barrier, increase accessibility, and automate the tedious parts.

The flip side, of course, is optimizing only for AI. As great as LLMs are at automating tedious interactions, they can fail (like humans). Either by making genuine mistakes, or by the user not specifying their intent correctly. In either case it’s important to ensure the user can take over at any time to intervene if they need to.

With human-AI parity, the user can choose which route to take, how much to automate with AI and when to take over. And it turns out, it’s fairly easy to achieve parity!

Two Ideas That Make Parity Easy

Frontend as the Main Control Gateway

The key design decision with MCP-Web, and maybe the most fundamental difference between a regular MCP setup and MCP-Web, is that with MCP-Web you make the frontend the main control gateway to data. Instead of having an AI agent operate through MCP on the data and pushing updates to the frontend, with MCP-Web both the human and AI are essentially using the same channel: the frontend state.

The human controls the frontend state through a graphical user interface while AI controls it through tools. The key is that both interfaces manipulate the very same state. While it doesn’t guarantee parity between humans and AI, this design at least makes it much easier to achieve parity. You just need to ensure that every state can be controlled through a GUI and an MCP tool.

As with every design choice, making the frontend the main gateway comes with tradeoffs. First and foremost, it requires the user to run the frontend app in the browser to interact with it. This requirement also limits some use cases like multi-user interactions. However, for visual interfaces and dashboards, which are meant to be seen by the user and that have rich view states, I believe this tradeoff is justified.

This design choice has another benefit: exposing UI components to AI agents becomes trivial. MCP apps, the new extension to MCP for exposing user interfaces, let AI agents render UI for human consumption. Since the frontend already defines all UI as components, you can expose them directly from where they’re defined, rather than duplicating the UI logic.

All this brings us to the question of what it takes, on a technical level, to achieve full AI controllability.

Declarative Reactive Frontend State

One of the main learnings from building MCP-Web is that 99% of the work to make a frontend app AI controllable has nothing to do with AI and everything to do with structuring your frontend state well.

tl;dr Well-described declarative reactive state is all you need.

At the end of the day, if you model your state declaratively and break it up into atomic and derived units, then it’s dead simple to enable AI to control your frontend app. Just expose the atomic units as tools. The only other key ingredient you need are well-described schemas. That’s it. You’re done! 🎉

Of course, there are nuances. Some states might need to be synchronized to avoid flickering and other states you might need content validation in addition to schema validation. But those things are easy to add if your state follows the declarative reactive framework.

One might point out that AI is also becoming better and better at understanding, navigating, and controlling rendered websites of all kinds. This is true and the performance will for sure only getting better over time. However, I’d argue it’s always more efficient and effective to offer declarative schemas as they take guessing out of the game and will always be token efficient. Especially for bespoke data visualizations, some interaction patterns might require parsing minified JavaScript code, which just seems like a waste of compute.

Learnings From Coding with Claude

Another reason for creating MCP-Web was that it provided me an excuse to see how far I can get with AI coding tools like Claude Code. Needless to say you can get very far very quickly if you know where you want to go. And the progress from when I started working on this last October to now is mind-boggling. With AI coding becoming cheaper, faster, and better month by month, I find it matters more and more what and why you want to build.

Knowing What You Want to Implement

I keep coming back to the question of what to build ever since I listened to the Hard Fork episode where Casey Newton and Kevin Roose interviewed Gary Greenberg who psychoanalyzed ChatGPT. Greenberg at one point said something along the lines of “if asking questions and getting feedback essentially becomes free, what matters is which questions you actually want to ask”.

When it comes to AI coding, I think the very same is true. If you have the financial means to pay for an AI coding tool, writing code is essentially “free”. The hard part then boils down to figuring out what exactly you want to implement and why. I.e., what problem is your software product trying to solve? Do your users actually have that problem? And is there even a reason to build shared software rather than letting each user have AI create their own bespoke solution? In other words, do the inevitable constraints your software imposes on users enable something new?

Once you’ve figured out these fundamental questions and you move to the coding phase, I learned that it matters just as much how you ask AI. The challenge is that the framing questions can inadvertently constrain the answers. If I ask “Should I use option A or B?”, AI will likely pick one, even when the real answer might be “Neither, consider C instead.” To avoid this, I find it better to pose open-ended questions, like “What viable approaches can you imagine for X?”, to prevent priming the conversation. (The same is true for human collaboration by the way). So beyond knowing what to build, I find it’s important to know how to ask the right question.

I wish there was a dedicated explore or discuss mode in Claude Code that focuses on offering different perspectives. Planning is great when you already know where you want to go and “only” want to flesh out the path of how to get to your target. I know you can get there using skills but it’d be wonderful if this was a first class feature. What, for instance, if your goal is not optimal? Or if there’s a totally different approach that’d turn out to be better?

The Old is The New

Many discoveries in this new age of AI software engineering are rediscoveries of things that were known for a long time.

For instance, execution is easier than planning, which is why it takes a lot longer to write a PhD thesis than a Bachelor thesis. For the latter your professor has already created a plan for you to execute while a PhD requires you to come up with a research plan yourself. And related to knowing what to ask AI to code, the hardest step is finding out what research to conduct and plan out.

Another example are evals, which are a hot topic everywhere right now. But evals are essentially just codified ways of grading, which teachers and professors had to deal with for centuries. I would also argue evals are just tests with non-deterministic outcomes that need grading. You’re testing against a distribution of outcomes instead of a single outcome.

Lastly, AI agent workflows and orchestration from a conceptual execution point of view share a lot of similarity with what computer scientists in the human-computer interaction community have studied under the topic of crowdsourcing. In both cases you deal with agents you cannot perfectly predict and that may or may not give you correct results.

Treating all problems as new when the technology changes is not a new phenomenon by any means. But while there’s a lot of excitement around the new, I find it helpful to remind myself that many challenges we run into with AI coding have historic parallels that offer useful learnings.

MCP-Web itself is a good example. Almost nothing in it is truly new. Declarative state? Established long ago in SQL, functional programming, and the grammar of graphics. Reactive frontend state? Knockout.js introduced computed observables over a decade ago. The patterns are old; the context is new.

What’s Next?

I’m pretty happy with the approach behind MCP-Web and what it can already do but it’s far from done. As always there are more things we can and will add. For now, I’m curious to see if others will find this library useful as well or whether I failed in my belief or approach to AI controllable frontend apps that offer human-AI parity.

In any case, it was fun building MCP-Web with Claude and at the very least I learned a bunch myself.

At Ridge AI, we’re building AI-native tools that let users intelligently create and explore data-rich visualization dashboards. I’m excited to push the boundary of AI-driven mixed-initiative visual data systems with such an amazing team.

To support large-scale datasets commonly found across industries, Ridge AI builds on the Mosaic architecture for scalable interactive data applications. Check out Jeff’s introduction: https://www.ridgedata.ai/blog/mosaic-architecture

If you’re working with large-scale datasets and want better ways to visually explore them, let’s chat!

Special thanks to my research interns Trevor, Devin, and Jane. It was great having you at Ozette and I deeply enjoyed doing impactful research together that pushed visual analytics forward and resulted in new production-deployed features.

I’m taking a short break to recharge and am super excited for my next journey! More details coming soon.

Exploring single-cell data can be challenging as the underlying science, data generation, and analysis is complex. To make it easier to get started, our recently-introduced AI agent enables you to chat with your data to quickly uncover insights.

Compared to classic chat interfaces, our agent not only provides text answers but also reconfigures the dashboard to visualize and highlight relevant data patterns. For instance, ask “Which T cell populations show activation markers?” and watch the dashboard automatically filter, highlight, and annotate relevant clusters.

Importantly, you remain in full control and can seamlessly switch between mouse and conversational interactions. Whatever the agent can do, you can do. To highlight how the agent adjusted the dashboard, you can now select an answer which shows all related UI elements.

The agent can now also trigger platform functions, like the newly added phenotype simplification feature that allows for finding simpler phenotypes that still express the same abundance pattern. You could think of this like feature selection for marker expressions.

Single-cell analysis shouldn’t require a PhD in data visualization. Our agent helps you get started as quickly as possible so you can focus on the biology instead of the UI.

To learn more and see the agent live, say 👋 to our team Cherie Green, Evan Greene, Greg Finak, Kurt Van Gunst, and Corrie Ortega at CYTO.

Designing a generic DataFrame-driven method that integrates with Jupyter Scatter’s overall API design was a fun challenge. I ended up modeling the label assignment via categorical/string columns, which groups points and shows a single text label per group. Point labels are also supported and you can assign as many label types as you need.

To learn how to use the new labeling feature see:

• Code: https://github.com/flekschas/jupyter-scatter
• Docs: https://jupyter-scatter.dev/labels
• Demos: https://github.com/flekschas/jupyter-scatter-tutorial/blob/main/notebooks/6-Labels.ipynb

The label placement is implemented using a dynamic map labeling approach to avoid over-plotting while maximizing the labels that can be shown across zoom levels. Label positions are computed upfront for performant rendering and can be persisted as parquet files for fast re-use. Additionally, the label data is tiled to allow limiting the total number of labels per tile and enable scaling to hundreds of thousands of labels.

Some fantastic libraries I learned about and use for labeling:

• Jeffrey Heer’s Flechette is a fast and lightweight library for loading Apache Arrow. Jupyter Scatter uses it to send label information between Python <> JS kernels as binary data. Flechette is perfect for this! Really nice work Jeff. 👏
• Kyle Barron’s geoindex is a fast, memory-efficient, zero-copy spatial indexing library for Python. Essentially the counterpart to Volodymyr Agafonkin’s fantastic KDBush which we’re using under the hood in regl-scatterplot already for statically indexing 2D points. 🙌
• Rye Terrell’s awesomeCandygraph library for plotting 2D charts with WebGL heavily inspired our text measurement implementation. Efficiently and precisely measuring the labels’ dimensions is critical for handling many text labels. 👏
• Thilo Spinner’s Colormap 2D is a library implementing various 2D color maps from Steiger et al.’s (2015) “Explorative analysis of 2D color maps”. 2D color maps are an excellent way to color points in data maps with many categories/groups/labels. 🙌

Finally, shoutouts to Trevor Manz for reviewing the quite involved PR and Leland McInnes’ wonderful DataMapPlot library which inspired the 2D color map integration and has many excellent shared examples. 🙏

Let me know what you think and happy scatter plot labeling 🏷️

This feature transforms how scientists interact with complex biological datasets - simply chat with your data to quickly uncover insights without needing to master the UI first.

Working with the wonderful Jane Adams, we tackled a fundamental challenge in life sciences visualization: how do we make complex visual analytics dashboards more accessible from a data exploration perspective?

Our solution is a mixed-initiative system where:

• An LLM-powered agent reconfigures the dashboard in response to natural language queries
• Users maintain complete control and can seamlessly switch between conversation and direct manipulation
• The agent operates within the same constraints as human users, ensuring all responses are verifiable and grounded in Ozette’s high-quality and standardized analysis pipelines

Unlike a classic chat interface, our AI agent doesn’t just generate text - it drives actual dashboard reconfigurations that show you the evidence behind its answers through interactive and linked visualizations.

This bridges the gap between conversation and visual data exploration, dramatically reducing the learning curve for complex scientific dashboards.

Huge thanks to the entire Ozette team and especially to Jane Adams who developed the initial prototype during her internship with us last year. 👏

We’ll share more details in the coming weeks/months.

Another highlight from ISMB BioVis is Devin Lange’s talk on a novel visualization method for aggregating annotated single-cell heatmaps. Devin Lange presents his internship research work from Ozette: https://www.youtube.com/watch?v=U8R1QrKTsbg (Pssst Devin actually gave two fantastic talks at ISMB BioVis! Make sure to check them both out! Great job Devin 👏)

You can find all ISMB BioVis talks at https://www.youtube.com/watch?v=kZxwndSEELw&list=PLmX8XnLr6zeEBBmvt6QI6RiiJFvpx8Xdh

Happy watching :)

The brush selection can be useful when working with temporal or sequential patterns. Huge kudos to Andres Colubri who brought up that idea and the initial implementation for regl-scatterplot (Jupyter Scatter’s rendering engine).

To test the new brush selection mode, I integrated Jupyter Scatter with a novel algorithm called DimBridge by Mingwei Li and Remco Chang et al. DimBridge aspires to identify key dimensions in the high-dimensional space that explain a subset of points in the lower-dimensional embedding. For instance, imagine working with a 2D UMAP or t-SNE plot of a 100 dimensional dataset and you see an interesting pattern. The idea of DimBridge is to tell you which handful of dimensions from the dataset can explain the pattern you’re seeing in the embedding plot.

Using a single-cell surface protein dataset from Florian Mair et al. that we analyzed with Ozette’s Cell Discovery method (an extension of Evan Greene et al.’s FAUST method) and embedded with t-SNE, you can use Jupyter Scatter to select a cluster and have DimBridge compute the key protein expressions of that cluster. You can also contrast two or more selections to identify proteins that differentiate them. Or you can use the brush selection to study a sequence of selections in the dataset.

To test it out yourself, head over to https://github.com/flekschas/jupyter-scatter, clone the repo, cd into notebooks, and run juv run dimbridge.ipynb. This requires you to have juv installed, a super handy new tool from Trevor Manz that makes Jupyter Notebooks reproducible! I highly recommend you check it out if you haven’t.

To cite a few from the blog post:

• Bioframe brings genomic interval operations natively to Pandas DataFrames. It operates directly on data frames rather than specialized data structures or wrapper objects.

• Pairtools is a critical suite of command line tools for processing and interpreting sequence alignments from proximity ligation NGS assays, like Hi-C.

• Cooler is a scalable file format and support package for storing multi-scale contact matrices and other genomic interaction maps.

• Cooltools provides common downstream analysis for Hi-C data.

Looking forward to what you guys release in 2025!

GitHub: https://github.com/flekschas/jupyter-scatter Docs: https://jupyter-scatter.dev

Another addition is the ability to change the point size’s zoom scale function. By default, points are scaled up using the inverse hyperbolic sine, which enlarges points sublinearly. This reveals structure of overlapping point clusters as you zoom in. But sometimes it can be useful to keep the point size constant (e.g., scatter.size(scale_function='constant')) or enlarge points linearly (e.g., scatter.size(scale_function='linear')). Finally, you can also now lock the camera view with scatter.camera(is_fixed=True) to avoid zooming in as you scroll through your notebook.

To give Jupyter Scatter a try is now easier than ever: ➡️ uvx jupyter-scatter demo

(This fantastic feature is shamelessly copied from Trevor Manz who implemented it for cev. Huuuge thanks Trevor 🙏)

Under the hood, we’ve modernized, i.e., rustified, the tooling by switching to Biome for JS code formatting and uv for Python package management. The minimum Python version is now 3.9. (Again massive thanks to Trevor Manz for taking on the switch to uv. Also a big shout out to the fantastic folks behind Biome and uv 👏)

See the full changelog at https://github.com/flekschas/jupyter-scatter/blob/main/CHANGELOG.md and let me know what you think!

And most importantly, Guten Rutsch and Happy new Year! 🥳

➡️ Test it yourself: https://github.com/OzetteTech/comparative-embedding-visualization

When working with multiple large-scale datasets (e.g., single-cell data), tools like t-SNE, UMAP, PCA, etc. are frequently used for plotting to get an understanding of the class distributions (like cell phenotypes). Unfortunately, when comparing multiple such plots (e.g., from two experimental conditions or two embedding models), the size, complexity, and distribution shifts of the data can make it challenging to identify changes.

Our solution is to compute metrics for groups of points as defined by class labels. This allows us to compare datasets without point correspondences and surface insights at different semantic levels. We do this by constructing a Delaunay neighborhood graph and dividing it into a core, context, and combined region for each class. Using the resulting subgraphs we summarize the class distributions to derive three metrics: confusion, neighborhood, and size. Confusion quantifies the visual intermixing of classes. Neighborhood measures the stability of neighboring class labels. And Size assesses relative class size differences in their local neighborhoods.

To evaluate and apply our framework+metrics we developed and open-sourced a Python-based prototype for Jupyter Notebook-like environments called CEV. Using Rust for computing the metrics, anywidget for the widget architecture, and Jupyter Scatter for rendering, CEV scales to datasets with millions of points. See https://github.com/OzetteTech/comparative-embedding-visualization/tree/main/notebooks for examples.

This fantastic work was led by the wonderful Trevor Manz from Nils Gehlenborg’s lab and started as Ozette’s first graduate research internship. With contributions from our Chief Technology Officer Greg Finak and Chief Data Science Research Officer Evan Greene, this was a fruitful long-term collaboration.

At Ozette we’re trying to push the boundary in single-cell analysis, not just by developing cutting edge machine learning methods but also by expanding the possibilities for efficient data exploration and discovery of actionable insights. This is just the first of several research projects on intelligent and scalable visual data exploration for single-cell data that we’re working on.

What’s Jupyter Scatter? It’s an interactive scatter plot widget for exploring large-scale datasets in Jupyter Notebook/Lab, VSCode, and Google Colab with ease.

But who cares about a software paper? 😅 To make the publications interesting, I added support for line-based annotations. You can now draw horizontal, vertical, or arbitrary lines to help locate and compare the position of points and clusters. For instance, to emphasize the point density you can now draw contour lines. For API details see https://jupyter-scatter.dev/annotations and for examples checkout https://github.com/flekschas/jupyter-scatter-tutorial/blob/main/notebooks/5-Cluster-Outlines-Contours.ipynb.

I’ve also updated the Jupyter Scatter tutorial with an example on how to implement text-based search using Jupyter’s Text widget and Jupyter Scatter’s selection() and zoom() method. See https://github.com/flekschas/jupyter-scatter-tutorial/blob/main/notebooks/5-Search.ipynb.

Want to learn more?

• Paper: https://joss.theoj.org/papers/10.21105/joss.07059
• GitHub: https://github.com/flekschas/jupyter-scatter
• Docs: https://jupyter-scatter.dev
• Tutorials: https://github.com/flekschas/jupyter-scatter-tutorial
• SciPy ‘23 Talk: https://www.youtube.com/watch?v=RyC5ixtQG-Q

Big thanks to Trevor Manz for his fantastic contributions to this multi-year project!

In my invited keynote talk at ISMB BioVis, I discussed the challenges and opportunities in creating integrated, composable, scalable, and interactive BioVis tools. At Ozette, we embrace these principles to build insightful and intelligent data visualization systems, enabling rapid identification of cellular biomarkers from large-scale single-cell data.

Key takeaways from my talk:

• Integrating BioVis tools into the compute and data ecosystem is essential for ensuring that insights can be gained fast.
• BioVis tools should be composable as complex analyses often require multiple visualizations to explain patterns.
• Scalability is essential for handling the vast amounts of data generated in biomedical research.
• Bidirectional interactivity is key to creating intelligent visualizations that offer AI/ML-guidance during exploration.

**In case you missed it, feel free to browse through my slides. The recording will be available on ISMB’s YouTube channel soon.

Some notable software tools that make it easier than ever to build integrated, composable, scalable, and (bidirectionally) interactive software are:

• Anywidget: Custom Jupyter widgets made easy.
• Jupyter Scatter: Explore datasets with millions of data points in Jupyter.
• Comparative Embedding Visualization: Compare two embeddings with shared labels.
• HiGlass: Explore and compare genomic contact matrices.
• Gosling: Scalable linked interactive nucleotide graphics.
• GenomeSpy: GPU-accelerated rendering for genomic data.
• Upset: Visualize intersecting sets effectively.
• Vitessce: Explore spatial single-cell experiment data.
• Viv: Interactive visualization of high-resolution bioimaging datasets.
• ipylangchat: Serverless Jupyter chat UI for LangChain conversational AIs.
• CandyGraph: Fast 2D plotting for huge datasets.
• Deck.gl: GPU-powered framework for large dataset analysis.
• DataShader: Accurate rendering of the largest data.
• Mosaic: Extensible framework for scalable data visualization.

This list is not exhaustive. If you know other great BioVis tools, please share them!

Last but not least, huge shoutouts to Trevor Manz, Ashley Wilson, Nezar Abdennur, PhD, and Arpan Neupane for their feedback on my talk and help with the examples and demos. 🙏

As one of the two invited keynote speakers, I’m super excited to talk about challenges in BioVis software tools and how we can overcome them with software best-practices and new exciting frameworks.

I’ll will discuss these practices and frameworks using examples from my visualization research in genomics and single-cell biology and the broader BioVis community.

Putting everything together, I’ll show a quick prototype of how we can make conventional BioVis software tools “intelligent” through bi-directional interaction between a user, the visualization, and an LLM.

Full BioVis Program: http://biovis.net/2024/program_ismb/

Data in the video from Mair et al., 2022: https://www.nature.com/articles/s41586-022-04718-w Tool in the video from Manz et al., 2024: https://github.com/OzetteTech/comparative-embedding-visualization/

Discovering high-resolution cell phenotypes is essential for finding biological meaningful biomarkers. However, at a first sight the details can be overwhelming. With Devin‘s work we‘re able to simplify the visualization without sacrifying the insights that can be surfaced.

See https://jupyter-scatter.dev/tooltip for more details. And check out https://github.com/flekschas/jupyter-scatter-tutorial for examples and demos.

📢 My talk on Jupyter Scatter – a widget for exploring large-scale datasets through interactive & linked scatter plots – is available at https://youtu.be/RyC5ixtQG-Q You can find the accompanying demo notebooks at https://github.com/flekschas/jupyter-scatter-tutorial

🙏 Many thanks to Trevor Manz for helping with the tutorials! In particular the cool genomics application with HiGlass, which I unfortunately didn’t have time to demo in the talk but you can check it out at https://github.com/flekschas/jupyter-scatter-tutorial/blob/main/notebooks/3-Genomics.ipynb

➡️ https://github.com/flekschas/jupyter-scatter

➡️ https://github.com/OzetteTech/comparative-embedding-visualization

To learn more, come to Trevor Manz’s talk on Effective Comparison of Single-Cell Embedding Visualizations in the BioVis track on July 25 11:50am CEST. In his talk, Trevor will showcase several use cases of single-cell surface proteomics embeddings. And in case you can’t make it, Trevor will also present during the BioVis poster session (B-062) on July 25 at 6pm CEST.

Check out https://github.com/flekschas/jupyter-scatter-tutorial for the tutorial & slides. In the tutorials we’re showing example on how to use Jupyter Scatter to explore single-cell, image, text, geospatial, and genomic embedding data.

Huge shout out to the absolutely amazing Trevor Manz for migrating jscatter to anywidget, helping out with the tutorial, and setting up the cool genomics use case with the HiGlass genome browser.

Also, our fabulous intern from last year – Trevor Manz – was also at the workshop and shared his thoughts on comparative embedding visualization and the tool he developed: https://github.com/OzetteTech/comparative-embedding-visualization.

Comparing multiple embeddings can be challenging due to batch effects, missing point correspondences, and the sheer complexity of of the data.

I’m super excited for Ozette Technologies’s first graduate research intern Trevor Manz to present his research work on addressing several of these challenges in comparative embedding visualization at Cyto’s “High Dimensional Cytometry” session today (Room 510B at 10:30am).

➡️ https://github.com/OzetteTech/comparative-embedding-visualization

Following our work on annotation-transformation embedding approach (https://github.com/flekschas-ozette/ismb-biovis-2022), Trevor developed graph-based metrics for comparing embeddings via shared point labels. The metrics quantify how much point labels are visually intermixed, how much the local neighborhood of labels differ between two embeddings, and how much the (cluster) size of labels change within their local neighborhoods between two embeddings.

Moreover, all three metrics can be applied across label hierarchies and to different samples as long as the labels are shared between the embeddings.

We developed a Python-based prototype for the Jupyter Lab/Notebook environment that you can find at https://github.com/OzetteTech/comparative-embedding-visualization. The API isn’t stable yet but feel free to give it a try! And let us know what you think. 🙏

If you miss Trevor’s talk, feel free to drop by our booth (Number 539) to learn more about our ongoing work and Ozette Technologies new suite of ML-powered tools for analyzing and exploring high-dimensional single-cell data!

Some new features that I added over the last year include fast point filtering, animated zooming to points, and lasso selection on long press. See https://vis.social/@flekschas/110180857858665444 for a demo video. (Pssst, if you code primarily in Python, all those features also made it into the Jupyter widget called jupyter-scatter https://github.com/flekschas/jupyter-scatter/)

But this is not the end, there are more exciting features in the pipeline that I hope to get implemented soon. Stay tuned!

If you’re working with single-cell data, check out the talks from Evan Greene and myself on clustering and embedding #visualization.

Evan presents a novel machine learning approach for unbiased discovery and annotation of cellular phenotypes in high-dimensional cytometry data that’s been foundational for Ozette Technologies.

🎥 https://www.youtube.com/watch?v=jrrvVnbda74 Related paper: https://www.sciencedirect.com/science/article/pii/S2666389921002348 Related code: https://github.com/RGLab/FAUST

I talked about a novel data transformations to create effective single-cell embedding visualizations that disentangle and align cell clusters across latent spaces. The transformations can be used with any dimensionality reduction methods (like PCA, t-SNE, UMAP, etc.)

🎥 https://www.youtube.com/watch?v=BSGQZIiVwtY Related code: https://github.com/flekschas-ozette/ismb-biovis-2022

Looking forward to more exciting research collaborations in 2023.

At Ozette Technologies, a biotech startup from Fred Hutch and AI2, we are looking for a graduate summer intern to research with us on the above-mentioned and related areas. If this sounds interesting to you, please feel free to reach out to me and apply at https://www.ozette.com/careers-apply/?jobid=4739131004#job-apply

I had an incredibly inspiring and fun 4.5 years of researching “Scalable Visualization Tools for Pattern-Driven Data Exploration” in Hanspeter’s Visual Computing Group at Harvard University (Harvard John A. Paulson School of Engineering and Applied Sciences) that came to a beautiful closure at last month’s make-up commencement for my 2021 graduation. 🥳

Thank you all!

➡️ https://medium.com/harvard-hci/ask-me-or-tell-me-c01a19bb05b5

In short: Asking an open-ended question first before stating the potentially negative or positive assessment results in better design revisions than just the assessment or just the question.

Great work with Spyridon Ampanavos, Pao Siangliulue, Hanspeter Pfister, and Krzysztof Gajos!

If you want to dive in deeper, below is our upcoming ACM CHI presentation and the paper. 📹 https://www.youtube.com/watch?v=qtZ1bYAfi1I 📄 https://vcg.seas.harvard.edu/pubs/ask-or-tell-me

PS: The awesome figure was created by the fabulous Pao Siangliulue

➡️ http://arxiv.org/abs/2101.06143

In short: Combine feedback statements with open-ended questions for better design revisions!

tl/dr; We investigated the effectiveness of crowdsourced design feedback that is framed as statements and questions on graphic design revisions. We found that a combination of both, where questions are shown before statements, led to the best design revisions overall.

There are two reasons why we think we saw these results: First, our results show that feedback framed as open-ended questions contains much less sentiment compared to the corresponding feedback statements. Having neutral sentiment is important because overly positive feedback does not promote significant changes in the design revision. On the other hand, negative feedback can be hurtful and make people ignore it. Moreover, questions can promote reflection and subsequently help us to focus on the design task, which can help to generate more ideas for the design revision.

Project page: https://piling.lekschas.de Code: https://github.com/flekschas/piling.js Demos: https://piling.js.org Publication: https://vcg.seas.harvard.edu/pubs/piling

Check out our video at https://youtu.be/FlzTdFUVE-M for a quick introduction and visit http://peax.lekschas.de for more details. Also, the code and data are freely and openly available at https://github.com/Novartis/peax.