Define navigation patterns: left sidebar, list/details layout, expand/focus mode

[benoitf]

trafficstars

How navigation should work in the product

[mairin]

Here is one idea on how we could have a secondary nav sidebar that can expand / collapse independently alongside the main menu.

[mairin]

Here is another nav option. It's based on Patternfly's drilldown menu pattern. It is a bit awkward to minimize - here, I minimize it just by sliding the bar all the way into the left with a (>) button to reopen it. This avoids having 2 menus. There are downsides to this:

• it makes having a full blown columned list of containers more challenging to display / navigate to, as the menu bar takes over that functionality.
• It obscures the other navigation categories. Here, I've made the preferences item persistent at the bottom because I believe that should always be visible. But it results in the Images top level nav item getting hidden when you are inside the Containers item.

It does provide a bit more horizontal screen real estate to follow this pattern.

[mairin]

Yet another option. Basically a tree-based menu. This has, over time, obvious scaling issues in terms of number of containers / number of images available. (see patternfly pattern for this, called "expandable nav").

It's a little awkward to minimize. The issue with minimizing the names of the containers (which applies to all options, honestly) is that oftentimes the container names are auto-generated and somewhat meaningless... the image name + chronological order of creation/running are likely more relevant to locating a container of interest. So ordering here is important wrt findability of the most likely to be relevant containers in the nav.

This is a better usage of horizontal space than having two nav layers.

[slemeur]

Thanks for all those mockups @mairin !

The third (last) iteration with a tree-based menu is not going to work well. The main issue will be that a user could get more containers/images which will make it very hard to display and navigate with this pattern.

The second iteration is IMO going to challenge the users who want to switch from one context to another one (for example: check images, get into containers, go back into images).

The first idea proposed is interesting with the left-sidebar which is collapsible. With the icons, even when a user is in a particular context (images, containers, pods or other) it is still possible to navigate onto another context. I think the second level of collapsible navigation (between the list of containers and container's detail) is going to be complex to implement and tricky to use. The main raison IMO, is that differentiating the items from the list with an icon is going to be really challenging - and most likely all items will look really similar.

I think the first idea proposed is the one we should continue to explore and refine. I think the left sidebar, collapsible/expandable works fine for the primary navigation. The "navigation" question still remains on displaying a list and details of one of its item. The main idea was to allow a user to easily switch from one item to another one, without having to navigate back to the list:

• Either we don't address this and we make the assumption that when a user wants to dive into one container, it'll be better to focus only on that container and utilize the entire screen for that.
• We allow the user to choose the layout. We could introduce buttons who would allow the user to display a "mini-list" of items or not. Similarly to what IDEs are doing.

[deboer-tim]

This is complete as of Podman Desktop 1.0 and there are open issues for follow-on work, so closing this.