VMS Mockups, First Review and Feedback

[pierpman]

Hi All,
Here is the first batch of VMS mockups for review.
The main goal was to experiment with Carbon and find a suitable layout and interaction pattern for each section. I started from the existing prototype and adapted it using the relevant Carbon and IBM Products patterns.
These mockups are still exploratory and are not ready for implementation. I made several assumptions about the domain model, available data, statuses, relationships, and actions. I also used the coding agent to inspect the current API and model, but some sections may still be oversimplified, overcomplicated, or based on incorrect assumptions.
At this stage, I would particularly appreciate feedback on whether the information, terminology, workflows, and relationships make sense. Please also highlight any missing states, technical constraints, or data that may not (or ever will) be available through the API.
I have attached the following files:

• Full PNG: (unfortunately, GitHub does not allow me to upload the SVG directly because the file is too large, but it is included in the ZIP archive.)
• ZIP archive: contains all the prototype files in PNG and SVG formats

Unfortunately, the Figma export does not include the comments. We can discuss the relevant comments and open questions directly in this Git conversation.
Feel free to add any feedback, questions, or suggestions here.

[pierpman]

@fgiorgetti @JPadovano1483 @ted-ross tagging you for visibility. No need for a full review, but any feedback would be very welcome, particularly on the model, backend assumptions, workflows, and overall design direction.

[JPadovano1483]

@pierpman To me, these mockups look very nice and are a nice improvement over the current UI. A couple of thoughts/topic for further discussion:

1. Login Page - Our current login page is served through Keycloak (not our React code) and redirects back to VMS after successful authentication. I looked briefly into changing this to a custom theme and it looks like it is possible if you mount a .jar file in the keycloak deployment. Currently, we are asking users to deploy their own keycloak instance before deploying the rest of VMS through our helmfile, so we would have to make a note about attaching that theme in a user's Keycloak setup, which may be more effort than it's worth.

2. I like the idea of having a "recent activity" panel. I think this could be useful for admin as an audit log, especially if we added what user triggered the event (or if it was system triggered). As far as implementation goes, I think there would need to be some backend work to get something usable. This may include adding a new postgres table to store these events and using the current watch/notify modules to get live updates to the UI.

3. Something to keep in mind / consider is the idea of different user types that can access the console. For example, an admin user, of course, should have access to the full UI, but a user that is only in the "van-owner" role doesn't need to be able to see the backbones tab. Currently, these roles dictate what API routes a user can successfully query, but there are no gates on the UI, meaning some of the UI basically just breaks if a user is unauthorized to see that data. There would probably need to eventually be gates on the tabs as well as maybe on specific components on the overview/dashboard page. This may even need to be taken into consideration for filtering things like "required actions".

4. One other thing I saw that would need to be wired is the "active user" block in the dashboard. There is a "websessions" table in postgres, but I don't believe it is wired anywhere at the moment. There is a lastseen timestamp on the "users" table. There isn't currently an API route that would give you any of that info though, but could be easily added if needed.

[pierpman]

Hi @JPadovano1483, thanks a lot for the detailed feedback. This is very helpful.
I was not sure how Keycloak would be deployed and managed, so I created the login page mainly as a placeholder in case a custom VMS experience was needed. We can either treat it as an optional addition or remove it from the current scope.
As you mentioned, the Active users, Recent activity, and System events sections would require some additional backend capabilities. I included them to explore the potential user experience. We can discuss whether to keep them in the mockups as future capabilities, show them as unavailable states, or remove them until the supporting model and APIs are defined. I agree that Recent activity could be particularly useful as an audit log, including whether an event was triggered by a user or by the system.
I also agree about permission-aware views. The UI will eventually need enough information to adapt its navigation, summaries, recommendations, and actions to the current user, while user and role management can remain in Keycloak.
Thanks again. I’ll capture these as discussion points and update the relevant mockup notes.