Apps Redesign: Installed Apps

[dszidi]

Installed Applications

General Improvements

In our new designs, the installed apps view follows the same paradigm as the new storage pages. A table is shown on the left with all the apps, and context cards are shown on the right. The table rows can be selected and the context cards will update with the relevant information. We feel this table centric approach is more practical for managing installed apps compared to the current app card grid.

Global Action

The UI provides a single global action on the page. Users can use the "Update All" global action button to update all apps with a single click.

Table

The table section is meant to display the data that users will most likely want to see at a glance. We've focused on the following columns.

• App Name
• Catalog
• Status
• Resource Usage
• Update Availability
• Action

Context cards

If the user wishes to get more details information about an installed application, they can click on a table row and the context cards will update in the details area. We will provide the following cards:

• Application Info
• Containers
• History (formerly known as application events)
• Notes (HELM chart notes)

Application Info

Containers

History

Notes

While the other cards show information the UI already exposes in Bluefin, the Notes card is new. The "Notes" term is being used since it is the terminology that HELM uses. It refers to the notes.txt file that charts provide. We will be exposing that information in this card. For more information about HELM and notes.txt, please visit the HELM documentation pages.

Summary

We feel that this design improves the installed app management in a number of ways.

• Moving to a table based layout is more appropriate for the task.
• The table provides app state, update availability and resource usage at a glance
• Context cards provide information with a single click that currently requires multiple user interactions

As always, we encourage and appreciate your constructive feedback. Please feel free to leave comments below.

[ptyork]

This is a logical change, especially for those that have a lot of apps installed. I like that it is easier to see the status of things at a glance in the table view. I don't think this is as necessary as the add/edit application screens as I think the current layout is okay (my only gripe being lack of "glanceable" summaries of start/stop status and upgrade availability). But I guess it makes some sense to add some consistency with other pages. Just a few comments.

• Would be nice to have an overview of number of apps installed/started/stopped, apps with upgrades available, etc.
• Why not have a shell link next to each pod name (like the logs link) instead of a single shell button. The popup for the shell command currently makes you then select the pod which seems unnecessary given you just left a screen with this same list. Which also applies to the current log button...
• The Delete button on the bottom of the details card feels out of place. Putting it next to the (potentially disabled or missing) Update button makes more sense to me. Or if that seems to likely to be mistakenly clicked, then the current ellipsis + drop down menu works pretty well...
• ...AND may be a good place for the seemingly missing Edit and Rollback buttons.

[Emalton]

I agree - especially being able to easily start and stop apps!

[Testpoint96]

It might be nice to have a global card showing all used ports by app. I see they are listed individually in each container.

[ptyork]

Great point! That's critical info. If not a separate card, then at least a column (potentially multi-line) on the list of apps. Could replace the update status with an icon if additional horizontal space was needed.

[jonct]

Alternatively: perhaps when there's no app selected, the space reserved for context cards should represent overall resource utilization.

For example: a CPU usage card could show a pie chart. Apps in color, core system usage in dull gray. A truncated legend names and shames the top three to five consumers, and ranks %apptotal against %systotal.

Likewise for RAM: a pie chart weighing app vs system needs, with a short hit list.

If near-term peak values can be determined, those would be helpful too. Maybe as tabs or toggles on the charts' cards themselves. (Or maybe such historical data belongs only per-app, not in aggregate.)

Then a simple table of open NodePorts could just show as a card of its own. 🤷

[jonct]

The Notes feedback will be immensely helpful for something like GitLab Runner which needs a second layer of coaching just to complete the installation.

CPU usage is useful, but ephemeral. Will it be refreshing often? Will that affect column width (and will Status and Updates do so)? Will rows shift around when sorted by that column and it polls with new data? (I'm sure I'm not the first person to worry about this; merely the first to mention it here.) 😉