[Bug]: Displaying Image version for OOTB Notebook images in Project View would be useful to have

[erwangranger]

Solutions

Review the UX screenshots: #1917 (comment)

• Add the version under the image name on the Workbenches table
• Apply a tooltip for the contents of the version description (same that we show in the Workbench form)

---

Is there an existing issue for this?

• I have searched the existing issues

Deploy type

Downstream version (eg. RHODS 1.29)

Version

RHODS 1.32

Current Behavior

Using the pytorch image as an example:

If I create 2 new workbenches using the 2 different versions, it's really hard to tell.

And even unfolding does not help that much:

Expected Behavior

This (highlighted in red) is the info I feel is missing:

Steps To Reproduce

No response

Workaround (if any)

No response

What browsers are you seeing the problem on?

No response

Anything else

No response

[dpanshug]

UX Context

Is Erwan's expected result what we want? is there anything else we want to add?
cc @xianli123

[xianli123]

Hi @dpanshug This is my first time to see this issue. I understood why Erwan wanted to add the version info. But in another issue #1520 we added some labels for different statuses. If we add both the status labels and version info, it will get a little crowded. So we should think about these 2 issues together and come up with a solution for them. Does it make sense?

[xianli123]

Hi @erwangranger @dpanshug I am not sure if the version info is important or not. But I think we can hide this piece of info if the version information does not affect the work of the workbench. As shown below, we can make the notebook image is clickable and has a popover to show the version info. This is a common interaction in RHODS UI. What do you think? Thanks!

[andrewballantyne]

I like the flow, only concern is how important is "the current image version" really important to the user. CUDA vs PyTorch is one thing... CUDA 2023.1 vs CUDA 2023.2 is probably not as important at the top level. But I agree the information should be visible.

My two cents @xianli123 @erwangranger

[erwangranger]

Information should be accessible somewhere/somehow. That is the critical piece (80%) for me.
Whether it's better as a popup or inline is of secondary importance to me (20%).

But if I had to make a choice, I'd say that the "deprecated"/"deleted"/"deleted" flags will hopefully not show up too often, and I still think that leaving the screen as it currently is:

is misleading to the user.
It really looks like I'm using the same image twice. And it's not until I'll hover over both Pytorch that I'll see it's not the case.
To me, if 2 things are not the same, they should not have the same name. (and this is why I called my workbenches in the screenshot, A and B, so that I could tell them apart easily).

My own opinion (I like knowing which version I'm using) is not necessarily representative of our target users, so UX colleagues, this is your call to make, and I'll be fine either way.

[xianli123]

Thanks @andrewballantyne @erwangranger Yes. I was convinced. I think we can just show the version info (with the Recommended text if it is) under the notebook image name as shown below and hide the advanced info in the popover.

As far as I know, the admin can disable or delete the whole notebook image instead of a specific version of the notebook image. So if the notebook image is disabled or deleted, we can add a label next to the notebook image name to indicate the status. The interaction will be the same as the issue #1872 fixed. What do you think? Thanks!

[xianli123]

I noticed the screenshot that @erwangranger attached. It's about the notebook image selection. I've seen this UI in another issue(but sorry I forgot which one).

But at first I was a little confused about choosing notebook image and version. I am not sure if we change the components from single selection to 2 dropdowns, as shown below. In this way, this part will have the same interaction as the notebook image selection in the workbench creation process. Of course, the previous design, being able to show all the options is a good point. What do you think? @andrewballantyne @erwangranger If it's worth a shot by using 2 dropdowns, I can create a new issue to update the design.

[xianli123]

This is the issue #1690 I mentioned. FYI

[erwangranger]

Sorry I used a screenshot from the Jupyter Tile. I should not have done that.
It's just that it had a bit more info than the double drop down:

I don't think we need to revisit that (^) design for now:

[xianli123]

@erwangranger Ok. Let's leave it as it is. What do you think about the solution that I shared?

[erwangranger]

Works for me. Thanks @xianli123 .

[andrewballantyne]

I have have assumed the state of the mocks to be complete @xianli123 and moved this to Dev Ready. Let me know if you're intending on spending anymore time on the mocks. I think we have what we need from a development perspective.

[xianli123]

@andrewballantyne Yes. It's ready for dev.

[harshad16]

With the current image streams:

• The build information would also be provided in the imagestream annotations:
  opendatahub.io/notebook-build-commit: <hash>

The requirement from UI would be to display this hash on the image selected view on the dashboard.
Along with the version info. i,e ex( PyTorch v1.2 e346hu8)

Notebook manifests are already loaded with these information: here
Dev Flag for Opendatahub development with this information:

workbenches:
      devFlags:
        manifests:
          - contextDir: components/odh-notebook-controller/config
            sourcePath: ''
            uri: 'https://github.com/opendatahub-io/kubeflow/tarball/v1.7.0-5'
          - contextDir: components/notebook-controller/config
            sourcePath: ''
            uri: 'https://github.com/opendatahub-io/kubeflow/tarball/v1.7.0-5'
          - contextDir: manifests
            sourcePath: ''
            uri: 'https://github.com/opendatahub-io/notebooks/tarball/2023b'
      managementState: Managed

[jstourac]

Hi guys, JFYI - just created this issue which may be related to this work https://issues.redhat.com/browse/RHOAIENG-348.

[andrewballantyne]

Migrated to the issue noted above.