List of operations widget - truncated summary text and missing path names in the navigation

[AnRei123]

Bug description

Depending on the browser window resolution, more or less text within the list of operation widgets can be truncated depending on the lenth of the names of the operations that are displayed via the list of operation widget.

Especially if the names of several operations start the same way, the distinguishing criteria might be hidden. In this case you are forced to click on each of the affected list items to find out the differences by reading the complete name in the header of the operation details widget.

Some developers complaint about this behavior as a very poor visualization and in some cases a useless navigation. Unfortunately, for our APIs it is not possible in all cases to shorten the names of the operations that they would work for all kinds of browser window resolutions.

Expected behavior

To get rid of the current poor behavior, the following options came into my mind:

Option 1 (truncated text, preferred solution):
Display a tooltip showing the complete name of the operation when hovering over a (truncated) list item.
The advantage of option 1 would be that the user has no additional clicks and could keep the focus on the currently read item during hovering over to see the complete name.

Option: 2 (truncated text):
Add a scrollbar to the footer of the widget.
The disadvantage of option 2 would be that in case of a very long list of operations, a scrollbar at the end of the list would not be helpful anymore.

Option 3 (truncated text):
Allow the user on the fly to extend the width of the column with the list of operations.
I would prefer to add this option in addition to option 1. Especially in combination when you allow to switch the views from listing the summary or the path names of operations in the same web widget.

If the tooltip for preferred option 1 is added to fix this issue, I propose to additionally display the suffix of the request URL with the path name. The path name would also be very important to see. Developers also complaint that the request URL got hidden if the descriptions of the APIs or the operations got very lengthy for a dedicated operation. As we do not have the URL suffix already used as the name for the operation summary, it is very important for the API consumer to quickly compare the different URL extensions across the listed operations of an API. To make the path names more prominent, I suggest to also add one of the following options for the missing path name information in the navigation across the operations:

Option 1 (path name): The path name could be either displayed in this widget as well by adding a second row in the same tooltip popup frame. This would allow the user to quickly check all operations for their request URLs without the need of clicking and reading the details for each of them. Our developer emphasized that a quick view at the request URLs would be very important as well and that they miss this with the current design of the portal widgets.

Option 2 (path name, preferred):
A switch button above the list of operations would be very helpful that allows to view and filter the list of operations by their pathnames including their parameters like the following:

The switch mechanism could be similar as how to switch between the raw data and the table view for the response body or definitions. But it should be per default displaying the summary of the operations. When clicking the switch view button in the list of operation widget the path names with the parameter should be displayed. And here also, a tooltip should be additionally provided when hovering over the pathnames in the list of operations to display the full path names as these might be more often truncated. Also here a slider to move the column border and to extend the list of operation width would here also helpful in addition.

Is your portal managed or self-hosted?

Managed

Environment

• Operating system: Windows 10
• Browser: Chrome (latest)

[mikebudzynski]

@AnRei123 Can you check if the proposed solution from #1019 would work for you?

[AnRei123]

Yes, thank you very much!!! It seems to work very well in my source instance. Hope it also work good after deploying it to other instances.