Rancher Desktop Designs

[rak-phillip]

Using the space to share this initial design proposal from the UI group. I've add some quick notes for each section of Rancher Desktop that might change. If you have any questions about anything you see below, please ask and I'll provide some more detail.

Feedback is highly valued and welcome.

About

• Rename "General" to "About"
• De-emphasize this menu option by moving to bottom of navigation

Settings

• Rename "Kubernetes Settings" to "Settings"
• Introduce two sections
  • Kubernetes Settings

    For managing things like Kubernetes Version and Port

  • Resources

    For modifying memory and # of cpu cores

• Replace "Reset Kubernetes" button with Apply & Cancel
• Move "Reset Kubernetes" button to Troubleshooting - Under Review

  Some discussions have revealed that this is not desirable, as having quick access for resetting Kubernetes and container images is beneficial for a lot of use cases. Hiding this feature behind troubleshooting might not be the best option here

• Move "Supporting Utilities" to its own menu item

Supporting Utilities

• Provide an area to control anything that might be considered a "Supporting Utility", like defining symlinks for macOS
• Add context to what we might be changing and how it will affect the environment through descriptions
• Explicitly commit changes through Apply actions

Troubleshooting

• Add context to any action we take and how it will affect the environment

Images

Images is where a bulk of the proposed changes reside. The goal is to make all the different actions we can take while working with images a little more focused

List Images

List all of the images, similar to how we do today with a few changes:

• Perform bulk actions, like scan, on multiple images
• Extract Image Acquisition as a child route for Images
• Scan results are viewable in as a child route

Image Acquisition

• Pull and Build actions are broken out into two separate tabs
• Output is rendered similar to how it is today

Image Scan Detail

• Output is parsed as table
• Ability to export results, if desired
• Link to CVE can be opened in browser window
• Any item can be expanded to view a description and list of references if they exist

Tray Icon

• Provide quick access to different areas by replacing Preferences with a menu item for each top-level navigation for Rancher Desktop

[jandubois]

About

• Rename "General" to "About"
• De-emphasize this menu option by moving to bottom of navigation

I would prefer to rename it to "Welcome" and leave it at the top.

Whenever RD terminates, it should store both the current version, and the currently active page in settings.

When you start RD, it compares the now current version against the stored version. If they are different, the starting page should be "Welcome". Otherwise it should be the same page that was shown when the app was closed.

This gives us a nice and friendly welcoming page, that the user is revisiting after each app update, so we can show the newly available features, or whatever else we may need to point out.

But during regular work, the "current" tab is maintained during app restarts, so the "Welcome" page doesn't get in the way.

[jandubois]

Settings

• Rename "Kubernetes Settings" to "Settings"

• Introduce two sections

  • Kubernetes Settings

    For managing things like Kubernetes Version and Port

  • Resources

    For modifying memory and # of cpu cores

This is a bit hard to discuss, as we haven't reached consensus yet how we want to support multiple container runtimes etc. So the following is just my vision on how I think it should work; I believe @mattfarina disagrees with at least some of my assumptions.

We are going to have multiple "runtimes" (for the lack of a better term right now), like

• Kubernetes
• Docker
• Containerd
• Podman

Each one will have their own settings that are independent from the other runtimes, so instead of renaming "Kubernetes Settings" to "Settings" I think it rather should be renamed to "Kubernetes".

I think we should have a global "Settings" page (maybe different name though), just below "Welcome". It would have a checkbox for each of the runtimes supported. As you check any of the boxes, the UI will add a settings page for each of the runtimes: "Kubernetes", "Docker", "Containerd", and "Podman".

I'm struggling to find a fitting name for "Resources": I think it is more general, as it should contain all the settings that are global to the virtual machine, and therefore shared by all the runtimes. So yes, memory and cpu settings, but in the future also maybe volume mounts, network configuration (dns and proxy settings), certificates, etc.

I want to avoid calling it "VM Settings", but maybe "Global", "Common", "Shared" settings? Either way, this page should be above the individual runtime settings, possibly directly behind "Welcome".

[jandubois]

I'm going to skip discussing the individual runtime settings pages in detail here, but just as an example, settings for "Kubernetes" would include things like:

• Use containerd or dockerd runtime
• enable traefik
• enable metrics
• (everything exposed by k3s that is meaningful to customize and doesn't break RD)

[jandubois]

Images

Images is where a bulk of the proposed changes reside. The goal is to make all the different actions we can take while working with images a little more focused

I haven't thought through the "Images" functionality yet. But it is getting more complicated:

If we allow multiple runtimes concurrently (and I think this is what @mattfarina wants to disallow, but I disagree, and want to discuss this further), then we can end up with multiple distinct image repositories.

E.g. we might run Kubernetes with containerd but also run moby for docker-cli access. So we have some images managed by 'containerdand some bymoby. Or even we only use containerd, we may have Kubernetes images in the k8s.ionamespace, and onces created bynerdctlindefault`, and the user may want to treat them separately.

So I don't know how this can be made natural in the UI. Potentially we need an image tab for each of the runtimes, even if they share much of the implementation.

I understand that disallowing multiple runtimes "solves" this problem, but I think there is value in being able to enable e.g. Podman to explore something new while keeping moby/docker working for your current projects. Let's discuss this maybe in person?

[jandubois]

One thing I want to mention explicitly (because it is annoying me in the current 0.4.1 and 0.5.0 implementation):

I think none of the pages in the app should have scroll bars and additional settings/navigation elements that are only reachable when you scroll the page. In the current app the "Supporting Utilities" section to create symlinks is hidden this way, and it feels very wrong to me.

I notice that none of the redesigned pages shown above have this issue, and I assume this is intentional, but I would like to call this out explicitly as a design goal.

[ericpromislow]

Agree with Jan on removing our reliance on scroll bars. For something like the output for pulling or building an image, maybe use an overlay textbox. We could keep the same flow for dismissing the box after the operation is done -- and we should also add a way to cancel an operation. The two main use cases are (1.) that the user quickly realizes this isn't what they intended to do, and (2.) that it seems like the operation is taking much longer than expected.

[jandubois]

Locking this topic now because it has been broken up into individual discussion items.