UX: Mockups for Docker Compatibility page

[slemeur]

Goal

The goal of this issue is to provide the mockups accordingly with the epic https://github.com/containers/podman-desktop/issues/8337

In this effort, we would like to reuse some of the component/information we are already using as part of the onboarding sequence.

Additional context

No response

[ekidneyrh]

@slemeur Will this page be nested withing the resources? Eg Setting > Resources > Docker?

Will this be part of the set up for Docker or a separate, more info heavy page? like when you look at recipes in ai lab

For the Compatibility Confirguration I presume that would be displayed in the preferences like the other resources settings?

Just want to know the context :) and visualize better where / what this page is

[slemeur]

As mentioned in the epic description #8337, we should introduce a dedicated page in the settings. It should not be nested under "Resources" nor under the "Preferences".

I believe, we can envision it more like the "details of recipes" from AI Lab indeed. With some mixed content, alterning descriptions, labels and links with other section where the user will actually be able to do some configuration.

[ekidneyrh]

Just an update on what I have as of right now.

I have a first draft of what the preferences might look like. I have it laid out like the preferences page. Toggles to enable / disable certain compatibilities. Socket Mapping has it’s own section with a status, a way to specify a specific path and an option to restore socket mapping.

I’m working on what the Summary page would look like at the moment. I’m just taking info from the docs so will hopefully have an update for this soon.

Let me know what you think of the preferences page!

[ekidneyrh]

Heres a draft of the Docker Compatibility Summary:

The copy can be changed, it's just a first go at it. I just included questions that were on the epic.

[gastoner]

Heres a draft of the Docker Compatibility Summary:

The copy can be changed, it's just a first go at it. I just included questions that were on the epic.

Looks good! I would maybe change the order of Summary and Preferences tabs. Since you are in settings so I think that you would like to change settings (preferences tab as first/default), but you can learn more about some of those settings in the Summary page

[deboer-tim]

I think the issue is more that the Summary page above is just docs (static text). As-is I'm not sure it's worth including, we could just have a link to docs within the Preferences.

[ekidneyrh]

@gastoner @deboer-tim Thanks for the feedback re: the summary page. In terms of the preferences page - do the options seem correct / relevant to docker compatibility?

[ekidneyrh]

Had a discussion with @Firewall about this last week. https://design.penpot.app/#/workspace/76981dd7-ec3b-802f-8001-9a56ef3fbc9d/82e31d90-3829-8139-8002-c1a6267ccc6a?page-id=00650e59-18b2-8059-8002-cea31c5415d6 was brought to my attention and I’m going to integrate some of the components there.

Some feedback: Have information on what the toggles do exactly When enabled - have feedback to show it’s working Test button next to status A more info button to explain actions

[gastoner]

@ekidneyrh I would say that the options are correct (but I'm not expert) + I'm looking at the Preferences and I would maybe put the Socket mapping status maybe one line up, to be in line with the title Socket Mapping since it does not look like you can set anything with it. But if will be added some button to test things, we can leave it as it is.

Agree

Have information on what the toggles do exactly When enabled - have feedback to show it’s working Test button next to status A more info button to explain actions

What about add something like "test tab" ?

[slemeur]

the "test tab" is such a good idea !

[shipsing]

@slemeur, I see this setting of Docker compose compatibility. With this setting enabled, users would not require to install and set up the Compose extension manually and they can use podman compose commands to run a Docker application. Am i correct??

[ekidneyrh]

Another update following the comments mentioned above.

I added a test button to the right of the status card and moved the status label to be inline with the card title.

I acknowledge the suggestion for a ‘test tab’ but I'm curious as to what would be displayed there. Would it just be the status card or would we have more components to display the testing.

Here’s an overview of the user flow:

I’ll go through each of the above screens.

Onboarding:

Still in progress

Settings > Resources > Podman:

Settings > Docker Compatibility:

Modal:

Docker Detected Warning:

[gastoner]

Regarding the "test tab" I got the impression that there will be a few options to test ~ 3/4+ (don't know which ones), but if there will be just one or two "test buttons" I think it is OK

[Firewall]

I have a feeling that we are repeating ourselves with the Docker compatibility mode and Compose support in Settings > Resources > Podman: and Settings > Docker Compatibility:. Don't you think this will be confusing for our users if those settings are in two places but have the same effect?

I like that the Test is just a button. Very simple. Where do you see those errors if the test fails to appear, a notification? Or inline somewhere?

[Firewall]

Regarding the test "Tab" I think idea was to display what the effect would be of switching the toggles. Then adding a button to see if that is working.

When you turn on Docker Compatibility, have a way to test if running a Docker command it will run it with podman instead. (eg, docker run ..., or tools that use docker internally quarkus image build ...)

When you turn on Docker Compose, have a way to test when a docker compose command is run, it runs with podman instead.

[ekidneyrh]

I have a feeling that we are repeating ourselves with the Docker compatibility mode and Compose support in Settings > Resources > Podman: and Settings > Docker Compatibility:. Don't you think this will be confusing for our users if those settings are in two places but have the same effect?

Would it make sense then to get rid of them from the settings > resources > podman page then?

I like that the Test is just a button. Very simple. Where do you see those errors if the test fails to appear, a notification? Or inline somewhere?

I was thinking having it display underneath like we usually do with our warnings / errors

Regarding the test "Tab" I think idea was to display what the effect would be of switching the toggles. Then adding a button to see if that is working.

When you turn on Docker Compatibility, have a way to test if running a Docker command it will run it with podman instead. (eg, docker run ..., or tools that use docker internally quarkus image build ...)

Could this be displayed as an error instead? Like have a test run in the background anytime it's turned on and if it doesnt work have the toggle reset to disabled and have an error underneath saying 'Error: Something went wrong' or something to that effect?

When you turn on Docker Compose, have a way to test when a docker compose command is run, it runs with podman instead.

Could this also be done automatically when the user turns the toggle on?

[Firewall]

Would it make sense then to get rid of them from the settings > resources > podman page then?

I personally think so, yes.

I was thinking having it display underneath like we usually do with our warnings / errors

Great, makes sense to re-use the same pattern yep.

Could this be displayed as an error instead? Like have a test run in the background anytime it's turned on and if it doesnt work have the toggle reset to disabled and have an error underneath saying 'Error: Something went wrong' or something to that effect? When you turn on Docker Compose, have a way to test when a docker compose command is run, it runs with podman instead.

Yea, I think we can add an error if it doesn't work (maybe it already does that). However the idea was more a explanation of what it is "enabling/providing" now that this feature is on. We could re-use the pattern we are using for the Socket Mapping having a 🟢 Active with an tooltip containing an explanation "Podman will handle all docker commands run on the CLI" (we can improve that message). Same for with the Compose support "Podman will handle any docker compose commands run on the CLI"

[benoitf]

hello, nice mockups

I have some comments

for

I think it's nicer if there is on the left the podman icon.

why ? because many providers may claim they want to use the /var/run/docker.sock

There could be podman, but lima, docker, etc.

Then, it's not because you enabled the toggle that it'll work as you expect. There is the rule of the 'last is the winner'. If I start podman in compat mode and then docker, docker will replace the socket so even if we're telling 'Podman is providing the compat mode', at the end it may be docker that is winning.

Then, about docker, in the past, docker was only using /var/run/docker.sock file, but now they're mostly advertising to use local sockets in the home directory and it's where is coming the docker context in the game.

docker cli is mapped to a context like

default                 System                         unix:///var/run/docker.sock
desktop-linux *   Docker Desktop          unix:///Users/<your-name>/.docker/run/docker.sock

so while you may think that when you're using the docker cli, you're using podman, if your context is mapped to a home folder, docker cli will continue to use docker engine

So for the compatibility, I would emphasis that it's the system compatibility (and say it's for /var/run/docker.sock if running on macOS, (npipe if on Windows)

Then, we should display on this page the current docker context of the CLI

and then, we might display what is really running behind the system socket (is it docker engine or the podman engine as depending of the order of the launch, you'll have different results)

For the socket Path entry and restore I don't know what it will do or what it means

so to summarize,

I would expect to see first if the system socket is alive (/var/run/docker.sock) and see what is the version/operating system behind (your test button but I think at each loading of the page I should have the result, not the need to click on the test) so as a user if I see that, it means ok I can use any classic tool, at least I have an engine that is working.

then, see the podman toggle to enable/disable the agent that is starting the socket note: AFAIK it's only on macOS on windows as long as you start a podman machine it will try

and then have a section where I see what context docker CLI is using. (is it system or home socket)

then yes we need the compose section (but it's provided by the compose extension so if the extension is not there or disabled you won't see that)

[benoitf]

overall status first and action after while in the mockup I see first the action and then the status/test

[ekidneyrh]

Following the UX meeting we had last week, I made the following changes:

Socket Mapping Status Added a provider label and changed the test button to refresh. Added in a detail section showing information about the socket. If there are no sockets or it is unreachable, the provider label will read ‘Socket not reachable’ and the detail section will not be there.

Third-Party Docker Tool Compatibility Added in that this is just for MacOS. On windows and linux this card will not be displayed.

Compose CLI Support Changed the card to just display an install button and if the CLI support is already installed, display an ‘installed’ label - like we do on the extensions page.

Deleted the Socket Mapping section and added a Docker CLI Context section.

Docker Context Similar to the Socket Mapping Status, this card displays details of the context. I wasnt sure whether to add a label in there but that can be reused from the Socket Mapping Status card. If there are no contexts an error will display to let the user know and the detail section will not be there.

Change Context Here we have a dropdown that will have all the available contexts for the user to choose between. It will display the context name and the socket. This will work like the other drop downs we have, where the option is selected and changed with no additional clicks.

@benoitf @Firewall Let me know if this makes sense / captures what we talked about last week.

Docker Compatibilty.pdf

[benoitf]

yes thanks @ekidneyrh

some notes:

1. Third party docker tool compatibility

I would add on the left card of the podman card to bring the system support the podman icon/widget

(because several providers can claim this)

Note: this card anyway would appear only on macOS as on Linux there is nothing and Windows it's always trying to bind if it's not taken.

2. Compose CLI support here in fact we're bringing docker-compose binary for podman compose if you install docker desktop on your system you have the support of compose with docker compose

so maybe here, add that card to the previous group saying it's for podman compose

• maybe also display a status in case it's already there like: podman compose supported | podman compose not supported

and yes if not supported, the command to install the support will help and a sentence to explain that without the support, you can't start compose projects using podman CLI.

3. Docker CLI Context

I would merge the two cards for CLI context. Why ? Let say I change the value in the dropdown, it means that I would need to click on the card before on refresh to get the value being refreshed.

So I would expect to have the dropdown on the left and the details on the right.

[ekidneyrh]

@benoitf Thanks for the prompt response! Implemented your feedback here:

Docker Compatibilty2.pdf

Does the text on the 'Podman Compose CLI Support' make sense?

[benoitf]

Does the text on the 'Podman Compose CLI Support' make sense?

yes thanks.

(I'm wondering if the podman icon/left box with the seal should not grow more and include the compose box)

I think we could remove the last widget 'Change Context' (probably leftover)

I'll try to implement and then we can discuss it from there as well

[ekidneyrh]

Whoops I forgot to delete the last card. Here's an updated version:

Docker Compatibilty2.pdf

Am I ok to close this ticket?

[shipsing]

A few questions: Now, the compatibility page does not have the options of providing a custom socket path and restore socket mapping as mentioned in the issue description.

What can a user do if they have to change the default path of the socket to restrict its access? If the socket is not reachable, what can a user do? how can i restore to the default settings?

There is an option to select a docker context, but where would a user define those contexts so that they get reflected in the dropdown list?

[benoitf]

@shipsing the UI in your screenshot does not seem to be the latest one.

you won't specify a custom socket path. The path is usually inside the tool you want to connect. (like I have a tool that needs to communicate with the docker API, then I can select the path)

we could display on this page all socket path where a user could connect

like this data

What can a user do if they have to change the default path of the socket to restrict its access? you just disable the system/podman socket if you don't want a system wide access. (anyway it's a socket on your local computer, not a remote one)

There is an option to select a docker context, but where would a user define those contexts so that they get reflected in the dropdown list?

docker context ls / docker context use <context-name> using the docker CLI.

then any docker ps command for example is connecting to the socket of this selected context.

by default docker can register default contexts.

[shipsing]

Thank you, @benoitf, for the detailed clarification.

[Firewall]

This is looking great so far. I would make a couple of changes to the descriptions to describe what these settings mean to our users.

For Socket Mapping Status I would change the text to: Displays which engine is currently listening to any commands on thedocker socket. If Podman is listening, it will emulate and run and any Docker commands with the Podman Engine instead.

For Third-Party Docker Tool Compatibility I would change the text to: Enabling this option will direct third-party Docker-compatible tools to use Podman. No changes will be needed in the tools Podman will handle the emulation once this is enabled.

For Podman Compose CLI Support @benoitf should it be Docker Compose CLI Support instead? and then the description: With Docker Compose CLI Support you will be able to run Docker Compose comamnds which will be emulated using the Podman CLI and Engine

For Docker CLI Context @benoitf can we only show this if the user has 2 or more Docker contexts on their system?

[benoitf]

while implementing I notice that displaying all the information like OS/Arch APIVersion, etc while it's a 'nice to have' is putting too much information there.

I thought then maybe it needs to be displayed on hover or a show/hide

I would change the text to: Displays which engine is currently listening to any commands on the docker socket. If Podman is listening, it will emulate and run and any Docker commands with the Podman Engine instead.

I believe it'll be too much text. I would carry some stuff behind ? hovering

After experimenting, I think I basically need to see the path of the socket (/var/run/docker.sock if macOS/Linux and npipe:////./pipe/docker_engine if Windows) and then to know the engine behind And if on macOS we can have a link and display the name of the connection providing the link like 'provided by Podman machine' and if you click you're redirected to the podman machine resource (or it's docker you're redirected to the docker resource also) and maybe here a toggle show/hide details where I can see some details. But probably as we're trying to redirect people to the resource page, the OperatingSystem/arch should be displayed there

For Podman Compose CLI Support @benoitf should it be Docker Compose CLI Support instead? and then the description: With Docker Compose CLI Support >you will be able to run Docker Compose comamnds which will be emulated using the Podman CLI and Engine

too early on my end to provide you meaningful feedback there

For Docker CLI Context @benoitf can we only show this if the user has 2 or more Docker contexts on their system?

yes, I was also thinking that we could display if docker CLI is found or not

[Firewall]

I believe it'll be too much text. I would carry some stuff behind ? hovering

Are you sure? It looks to me we have quite a lot of space for text? I think there is a lot of value in also explaining to the users what this means.

yes, I was also thinking that we could display if docker CLI is found or not

Good idea, we can do both?

[benoitf]

here is how following the mockup I can display things

but then, in case of macOS, I'm able to detect which podman machine is emulating the socket so I thought we could provide a redirect link to the podman machine providing that

on Windows it won't be possible for now to know what is the podman machine behind, so we need like multiple "right card option"

we can change the text on the left based on the provider type 'podman' or 'docker'

[ekidneyrh]

@benoitf do you mean that for Windows there wont be any info available on the right side of the card? or just that the second option wont be available on windows?

[benoitf]

@ekidneyrh on Windows, we're not able to detect (technical POV, upstream RFE filed in podman repository) which podman machine is binding the system socket so we can't provide the nice 'click here to go to the resource or the name of the podman machine providing the socket. We can only query the socket and get information like the version, etc

[ekidneyrh]

@benoitf can we have it this way then in windows?

or are we looking for another way to display it?

[benoitf]

we can display this way but I don't know if we need to see all fields/values directly or like after a clicking on a toggle (minimal state / all details)

[ekidneyrh]

I'm just wondering what would we have it behind then? Maybe a 'see details' text next to the open button? I wouldnt go with the toggle as that would be more for changing something bigger than just showing more details on something.