Dashboard wireframes for core functionality

[PardhavMaradani]

Hi @orbeckst, @jeremyleung521, @amruthesht, @HeydenLabASU,

I intend to use Vue.js, which is a progressive JavaScript framework to build the user interface for this project. Vue provides a lot of tools to build a reactive dashboard. It is simple to start with and can extend very well to something more complex in the future too. It has extensive documentation and community support. For the UI components, I intend to use Vuetify, which provides a rich set of ready-to-use components for Vue and is based on Google's Material Design. I found this a lot more easier to setup (compared to other equivalent options) and quite flexible too. Some of the other tools relevant for this project in this ecosystem are Vite, which provides the frontend build system and Vitest, which is based on Vite and provides the testing framework for all our frontend code. All the above tools are open source, have great documentation and community support.

I built some initial wireframes using the above for the core functionality of this project. Below are some screenshots of these followed by some thoughts behind the design:

Dashboard

Below is the main dashboard layout:

App Bar

There is an app bar at the top that is common for all pages and includes controls to pause / resume and connect / disconnect (from) the live simulation. It also displays alert details if any. Having this common makes it very easy to control the current state from any page:

Sticky Bar

There is a sticky bar right below the app bar that shows details like frame number and time info (if time packets are sent from simulation). The % completion of the simulation is also shown if the total simulation steps are configured (see settings later). The reason it is called 'sticky' is because it will remain at the top even when the pages are scrolled. This is also common to all pages like the app bar.

The color of the sticky bar also indicates the running state - running (green), paused (amber), disconnected (red), etc like shown below:

Alerts

Most recent alerts can be viewed by clicking on the Alerts icon. They can also be marked as read by clicking on the green check mark icon (which removes it from this list and reduces the count shown):

For the core functionality, we just need an additional Settings page that can be accessed from this app bar:

Energies

The dashboard shows the Energies live (if energy packets are being sent from the simulation) - see first image. This can also be hidden from the settings if needed.

Widgets

Widgets can be added using the Add Widget button. Clicking on this button shows the list of all available widgets along with an option to search and add the required widget (The widgets for the plots of energies only show up when energy details are available) as shown below:

Add Widget

Selecting a widget item from the list above navigates to an Add Widget page where the widget name and inputs for this can be customized as shown below:

The live output of the widget (the output of any of the packaged analyses - text, graphs, etc) will show up live (i.e., updating) in the Output section here. All input changes are reflected real-time and automatically saved. This is also the same view when the widget is edited later (to change inputs / name). There is an option to delete this widget at the bottom of this page as well.

Widgets rearrangement

Widgets on the main dashboard can be re-arranged in any combination by users (resize, drag and move, etc). Each widget also has options to edit (which shows the view mentioned above), duplicate (to make it easier to add same analysis with different inputs) and delete as shown below:

Widgets filtering

Widgets can also be filtered (by selection or text input) by their name to make it easy to focus on anything particular as shown below:

Settings

The Settings page has three main sections that allow universe configuration, dashboard configuration and details about universe setup as shown below:

Universe Configuration

The Universe Configuration section has all the config options relevant for imdclient, the step size (to iterate) and the total simulation steps (to show % completion) as shown below:

Dashboard Configuration

The Dashboard Configuration section has config related to mdadash. For now, this has an option to show / hide energies (when available) and the sliding window / batch size for analyses that use that mode as shown below:

Universe Setup

The Universe Setup section allows users to customize the universe during creation, like adding transformations etc. The imdclient session info details are also shown above it so users know what is available as shown below:

The code in these cells fully support code complete and inspect (because these run in the AsyncKernelManager of jupyter_client) as shown below:

All the wireframes above put together should cover the core functionality and these can also be very easily extended.

Demo Video

Here is a short video showing these in action:

2026-05-14.21-08-38.mp4

Responsive Design

The UI is responsive as can be seen here in a mobile view:

Please let me know if you have any thoughts, comments, feedback or suggestions and I can modify these accordingly. Thanks

[orbeckst]

Your UI looks very neat and well thought out. I assume we'll come back to this page a couple of times to review different aspects of the design. Could you make it more easily browseable by adding markdown sections, e.g., ## Settings, ## Responsive design, etc ... ?

I also have a question regarding widgets: Is it possible to save a set of widgets with all its configuration choices and load it in the dashboard? I'd expect users to not only look at a single simulation but perhaps 10 of the same system where they might want to monitor the same 6 different observables, some of which may have been customized to the system.

More long term, we might want to think about ensemble monitoring — what do my 20 or 50 simulations do at the moment?

[HeydenLabASU]

This indeed looks great! I love the adaptability and the integration of features like code auto-complete etc. This is very neat!

Regarding Oliver's comment, I agree that it would be neat to load a set of widgets, e.g., from a configuration file saved locally. Then, if one has a couple of things one wants to do routinely, one can load the entire setup with a few clicks.

Analyzing ensembles is also a cool idea. Maybe not for starters, but definitely something to keep in mind when designing the backend.

[PardhavMaradani]

Could you make it more easily browseable by adding markdown sections

Updated

Is it possible to save a set of widgets with all its configuration choices and load it in the dashboard?

it would be neat to load a set of widgets, e.g., from a configuration file saved locally. Then, if one has a couple of things one wants to do routinely, one can load the entire setup with a few clicks.

Yes. The proposal mentioned this in the context of persisting the state and import / export of the dashboard for these exact use cases. The entire dashboard state, including the layout of the widgets, their inputs etc can be restored and re-used. Though the proposal described using sqlite3, thinking about it a bit more later, using a json based config seemed like a better idea because it is simple, human readable, git friendly and we can use the same file for the backend state as well as import / export from the GUI. (I will bring this discussion up at a later stage with more details)

More long term, we might want to think about ensemble monitoring — what do my 20 or 50 simulations do at the moment?

Analyzing ensembles is also a cool idea. Maybe not for starters, but definitely something to keep in mind when designing the backend.

This is a good use case to know. Theoretically this should be feasible through the support for multiple universes and is something we can ensure the backend design considers from the beginning. It might be a bit too much to expose in the UI at the beginning, but it is something we can certainly extend in the future.

Thanks

[amruthesht]

@PardhavMaradani I really like the UI and overall design along with the various features and would second Oliver and Matthias' thoughts.

I just had a few additional comments/suggestions/questions:

1. Good call on Vue.js - its super convenient and neat!
2. Currently, where exactly are you parsing Done% from? Are you also planning to read user-input files? Keep in mind, that information might not always be available to the client/MDA calling code.
3. On the universe setup page, it might be helpful to have a short description of the IMDClient arguments in a thoughtful form.
4. It might be useful to have session-info displayed on the page where you can add widgets, helping the user decide on functions based on info at their disposal
5. It might also be useful to display trate (calculated) in a thoughtful form. This would enable the user to come up with analysis based on the information rate that is at their disposal.
6. Q - Will these widgets (analysis) run in parallel by default. Can the user customize it based on the resources (cores/threads) they have?
7. Not a priority - but I think you could possibly view this dashboard on VSCode, since its a wireframe. That could give you a lot more functionality for the custom widgets/universe setup coding segments?
8. Q - Maybe I'm missing this, but is there an option to write custom widgets with custom user defined analysis routines?
9. If yes, then for eg. I'm visualizing a calculated quantity X as a timeseries. I'm assuming the actual visualization call and analysis loops are asynchronous right? Will the user have to specify it by some means for a custom analysis routine? If the visualization creates a bottleneck does it have a means to say communicate with the MDA loop to pause the simulation if necessary?

[PardhavMaradani]

2. Currently, where exactly are you parsing Done% from?

Given that the total simulation steps are not available from imdclient, there is an input under 'Universe Configuration' (see image above) at the very end called 'Total simulation steps' with a hint / description '(Configuring this will enable showing % completion)'. If this is configured (and if we have time packets being sent, which has the current step info), we compute and show the % completion.

3. On the universe setup page, it might be helpful to have a short description of the IMDClient arguments in a thoughtful form.

Sure

4. It might be useful to have session-info displayed on the page where you can add widgets

Sure. I initially had it on the main dashboard page where we can add widgets, but since this info is static, wasn't sure if it was useful there and hence moved it under settings. Will bring it back.

5. It might also be useful to display trate (calculated) in a thoughtful form

This is not clear to me. I am assuming this is not the transmission rate sent from the client (which is not yet available as per Becksteinlab/imdclient#123). If this is something that can be calculated, we can definitely display it

6. Q - Will these widgets (analysis) run in parallel by default
7. ...I'm assuming the actual visualization call and analysis loops are asynchronous right?

Would it be ok to defer this for a more detailed discussion soon? I just started working on putting together details for another discussion about the execution layer that handles all the multiple analyses (widgets) and I believe most of these will get clarified there.

7. Not a priority - but I think you could possibly view this dashboard on VSCode

Possibly, but I will have to check as I am not familiar with it

8. Q - Maybe I'm missing this, but is there an option to write custom widgets with custom user defined analysis routines?

The wireframe prototype I showed during the initial meetup call had an option to create separate notebooks from within the dashboard that could be used to write custom user-defined analysis widgets. However, since it was mentioned that the initial priority was the core functionality and extensibility later, I hid it from the core functionality wireframes here. I intend to add this after the core functionality is done.

Thanks

[jeremyleung521]

Looking good!

Given that the total simulation steps are not available from imdclient, there is an input under 'Universe Configuration' (see image above) at the very end called 'Total simulation steps' with a hint / description '(Configuring this will enable showing % completion)'. If this is configured (and if we have time packets being sent, which has the current step info), we compute and show the % completion.

Regarding this, it would be nice that imdclient could report it. Not sure the feasibility (and the scope of the project) allows modifying IMDClient's protocol though.

You could also potentially calculate & show an estimated completion time (after at least two steps reported to the dashboard) for the simulation and maybe the "timestep/day" or "ns/day"-like efficiency metric. Those are always helpful when I track MD simulation progress.

---

Visually, I think the running/paused/stopped background colors could be darker and less pastel-like, with a larger play/pause/stop symbol. I think it didn't help your chrome tab bar is also peach and the sticky bar is blue!

[amruthesht]

Given that the total simulation steps are not available from imdclient, there is an input under 'Universe Configuration' (see image above) at the very end called 'Total simulation steps' with a hint / description '(Configuring this will enable showing % completion)'. If this is configured (and if we have time packets being sent, which has the current step info), we compute and show the % completion.

Oh, I missed that detail. This looks good to me then!

Would it be ok to defer this for a more detailed discussion soon? I just started working on putting together details for another discussion about the execution layer that handles all the multiple analyses (widgets) and I believe most of these will get clarified there.

Yes, lets discuss this in more detail during one of the upcoming weekly meetings.

The wireframe prototype I showed during the initial meetup call had an option to create separate notebooks from within the dashboard that could be used to write custom user-defined analysis widgets. However, since it was mentioned that the initial priority was the core functionality and extensibility later, I hid it from the core functionality wireframes here. I intend to add this after the core functionality is done.

Yes, that's completely alright.

This is not clear to me. I am assuming this is not the transmission rate sent from the client (which is not yet available as per Becksteinlab/imdclient#123). If this is something that can be calculated, we can definitely display it

Yes, this would be calculated quantity when time packets are being streamed, you could calculate trate from consecutive steps of frames received

[amruthesht]

I had a separate question/suggestion I just noticed -

1. For the universe setup, do the input topology format and file paths have to be spelled out relative to where the dashboard was launched from? Would it be possible to interactively select the file by browsing through user's file structure (maybe too much detail for the first iteration)
2. For file types like the .xyz and .data in LAMMPS, the Universe requires a bunch of additional arguments to be able to read in LAMMPS topology file.
   u = mda.Universe(LAMMPS_TOPOL, "imd://localhost:8887", topology_format="DATA", timeout=50000)
   Further, the user may want to add additional kwargs. It might thus be useful to just have a custom field where the user can add the argument name and value?

[PardhavMaradani]

1. For the universe setup, do the input topology format and file paths have to be spelled out relative to where the dashboard was launched from?

There are a few considerations for configuring file paths from the dashboard and each has its own pros and cons. The primary reason is that the machine where the dashboard server is run could be different from where the dashboard is accessed from (i.e., client browser). Restricting the dashboard to the localhost of the server could be very limiting (especially for collaborative use cases). The options are:

• Allow users to configure paths (as strings) that are relevant (could be absolute or relative) from the dashboard server perspective
  • This is easy, but not very user friendly as you rightly pointed out above
• Allow users to upload files (topology for now, since the trajectory is a URL in the current case) from the dashboard
  • The uploaded file is typically available as a temp file on the server side and hence needs separate handling for server re-launch scenarios etc
• Allow users to interactively browse and select files from the filesystem where the dashboard server is running
  • This could get fairly complex (as it is different from standard file inputs and the details have to come from the server side) and runs into permission issues etc on the server host machine
• Allow users to specify them when launching the dashboard
  • This is easy, helps with validation and potentially auto connect to the live simulation (i.e., create the universe)
  • As you asked during the call, users could also explicitly connect from the dashboard too (maybe after specifying additional params that you mentioned here)
  • For the ensemble of simulations use case later, these could come from a config (yaml) file passed to the dashboard server during launch as well

I was thinking along the lines of the last option above. The UI doesn't quite show it well here, but these two inputs were marked readonly considering this case. I will start simple here and we could review and evolve as needed.

2. ...It might thus be useful to just have a custom field where the user can add the argument name and value?

This is useful to know. I will add an option to specify custom kwargs (as separate name, value pairs).