[FR] "Share" button for experiment UI views

[dbczumar]

MLflow Roadmap Item

This is an MLflow Roadmap item that has been prioritized by the MLflow maintainers. We're seeking help with the implementation of roadmap items tagged with the help wanted label. Items tagged with the needs design label are awaiting a design sketch from an MLflow maintainer: @sunishsheth2009.

For requirements clarifications and implementation questions, or to request a PR review, please tag @sunishsheth2009 in your communications related to this issue.

Proposal Summary

Introduce a "share" button that can be used to share a view / configuration of the MLflow experiment UI with other users. This button should generate a link that, when opened, configures the MLflow experiment UI to display the same Runs table columns, search query, and table ordering properties that were selected when the link was generated.

Motivation

• What is the use case for this feature? There are many toggles / options for configuring the MLflow Experiment UI. For example, Runs table columns can be shown / hidden, search filters can be applied to the table, and different column orderings can be selected. Being able to share a particular UI state ("view") is important because it lets multiple users / colleagues easily examine and discuss the same set of runs, parameters, tags, metrics etc without requiring each user to manually configure the same UI state.
• Why is this use case valuable to support for MLflow users in general? MLflow is a collaborative tool. This feature will facilitate collaboration when evaluating training results via the MLflow UI.
• Why is this use case valuable to support for your project(s) or organization? Many Databricks customers use the MLflow UI to collaboratively share training results and identify optimal models.
• Why is it currently difficult to achieve this use case? Multiple UI configuration steps are often required to identify a set of relevant runs and provide insights. When sharing these insights with other users, each user must manually configure the experiment UI in the same way, which is cumbersome.

What component(s), interfaces, languages, and integrations does this feature affect?

Components

• area/artifacts: Artifact stores and artifact logging
• area/build: Build and test infrastructure for MLflow
• area/docs: MLflow documentation pages
• area/examples: Example code
• area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
• area/models: MLmodel format, model serialization/deserialization, flavors
• area/projects: MLproject format, project running backends
• area/scoring: MLflow Model server, model deployment tools, Spark UDFs
• area/server-infra: MLflow Tracking server backend
• area/tracking: Tracking Service, tracking client APIs, autologging

Interfaces

• area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server
• area/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Models
• area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
• area/windows: Windows support

Languages

• language/r: R APIs and clients
• language/java: Java APIs and clients
• language/new: Proposals for new client languages

Integrations

• integrations/azure: Azure and Azure ML integrations
• integrations/sagemaker: SageMaker integrations
• integrations/databricks: Databricks integrations

[marijncv]

Hey @sunishsheth2009, I'm looking to try and implement this FR and was wondering about some points.

Right now, most of the state related to what is shown in the experiment view is stored in two separate objects here (ExperimentPagePersistedState & ExperimentViewPersistedState). Is there a good reason for them to be separate like this? I feel they are similar enough to be in the same object and handled the same way across the ExperimentPage and ExperimentView components. That would make exporting the state to a url simpler as well.

Some of the state is already being pushed to the query parameters in the url (such as search string and column to sort on). What are your thoughts on pushing all the other state changes (categorizedUncheckedKeys, runsExpanded, showMultiColumns etc.) to the url query params? If all the state is pushed to the query params, the share button would simply copy the url to the user clipboard.

In the meantime I'll work on a bit of a prototype and share my thoughts

[sunishsheth2009]

Well I feel, ExperimentPage would maintain state for experiments page and same for experiment view. We can lift the state up when we need the state to be shared across multiple components. I don't think that is the case here. Each component maintaining its own persistent state does sound good.

I do agree adding things to the URL does make it easier to share the URL. We can surely do that. But, we need to consider what all is important to be shared. Example, sharing if the runs are expanded or what columns are expanded/order of columns might not be super useful. So can we list the things that we feel are important that could be part of the URL and necessary for sharing?

[marijncv]

Thanks for the response @sunishsheth2009. I created a draft PR with a prototype for this FR. It adds the share button that copies the current url to the users clipboard and displays a small notification message. Also, the prototype maintains the following state in the url:

• search
• startTime
• orderByKey
• orderByAsc
• categorizedUncheckedKeys

The other state elements that could be included with the share button are:

• runsHiddenByExpander
• runsExpanded
• showMultiColumns
• unbaggedMetrics
• unbaggedParams

I think adding the the showMultiColumns to the share button makes sense, but not sure about the others. What do you think?

Finally, I ended up lifting the state of categorizedUncheckedKeys from the ExperimentView to the ExperimentPage to make the state setting from the url done in one place. Curious to hear your thoughts about that.