Empathy exercises helped me see Dashboarding through a bird's eye view.

Use Case (As described in Jupyter Dashboard READ.me)

“Alice is a Jupyter Notebook user. Alice prototypes data access, modeling, plotting, interactivity, etc. in a notebook. Now Alice needs to deliver a dynamic dashboard for non-notebook users. Today, Alice must step outside Jupyter Notebook and build a separate web application. Alice cannot directly transform her notebook into a secure, standalone dashboard application.”

Jobs to be Done

I hire JupyterLab Dashboards to:

Present complicated work in a consumable way.

Provide real-time insights into constantly changing data.

Consolidate important parts of my work into a single source of truth.

Users drag and drop pieces from open notebooks, or by dragging and dropping from the Table of Contents extension in the left sidebar. The Table of Contents (ToC) as a means for dashboard creation has several benefits:

1. ToC provides easy access to all parts of a notebook. The ToC is a condensed view of an entire notebook that exists in the left sidebar.
2. More space for your canvas. By using the sidebar, we are saving real-estate in the main canvas area that would have otherwise been taken up by a notebook tab.
3. Reusing established conventions from other dashboarding software. Rather than retraining users who have experience creating dashboards, we let their mental model of dashboard creation work for us (left sidebar as a means).

When dragging and dropping notebook pieces into the dashboard canvas, docking and tab splitting follows phosphor.js drop zones and auto-resizing logic. The first piece fills the entire canvas, then the next fills up half (depending on where it's dropped, either horizontally or vertically), and so on.

Some design changes to the ToC were made for purposes of dashboarding:

Tiles are widgets within your dashboard that represent pieces from your notebook. I experimented with low-fidelity layouts before iterating to higher-fidelity.

The final tile design consisted of four elements:

1. Notebook status indicator. For a dashboard to be dynamic (updating based on real-time changes) it must be connected to a notebook. The indicator surfaces whether or not the tile is connected to the notebook (circle not filled), or needs reconnecting (circle filled).
2. Notebook Cell. This is the main content of the tile, either markup, code, or a visualization.
3. Dropdown Menu. For further actions on the tile, such as saving the tile as an image or making the source path of tile visible or not.
4. Source Path. Initially toggled off, the source path is needed to identify which notebook the tile came from if the status indicator is disconnected.

Dashboards are meant to be viewed and presented. The preview button in the toolbar strips away unnecessary UI elements for a presentable view of the dashboard.

Dashboards are connected to Notebooks, which are connected to kernels (what runs and checks the code). There needed to be a way to "package" all of these components together. After a discussion with software engineers, I decided to go with the .zip packaging route, where a .zip file is created containing the dashboard, notebook, and layout metadata for sharing.

After 3 rounds of iteration, feedback from the open-source community, my final deliverable was a working prototype of the user flow of creating a dashboard, editing and resizing dashboard tiles, packaging a dashboard, previewing a dashboard, and launching a dashboard.