As part of the reassessment of the experience of finding and installing gitlab managed apps on a cluster, we decided to explore new designs that scale and modernise the look and feel of the page, as well as enhance the information presented to the user around the applications.
This issue deals with card design explorations for the applications, including alerts, status and card actions and interactions.
Great effort! @mvrachni I created this issue before the holidays to add an indicator of whether a service is active in Settings > Operations. Seems like you're addressing a similar issue as part of this redesign for GitLab managed apps on a cluster.
Also, I wonder if we should rethink the way we present services in Settings > Operations to follow the new pattern?
I wonder if we should rethink the way we present services in Settings > Operations to follow the new pattern?
Do you mean introducing this card design to the Settings > Operations page?
The current list view on Settings > Operations follows the same list pattern as all of the other settings pages. So, if we moved to the card view for Settings > Operations, I'm guessing we'd need to re-think all the other settings pages, as well, to ensure that these pages are presented in a consistent way. Since that would likely be a pretty big effort, I'm guessing we'd likely only undertake that work if there was a pressing need (like, if the way these pages are functioning currently isn't working for users).
With regards to the active indicator - yeah, I agree, let's keep an eye on this issue and try to align the representations of active and installed if possible!
On @ameliabauerly's point this would be a larger piece of work requiring many teams to align. Saying that I think it would fall within the beautification scope but would also serve as a usability improvement work and it might be worth adding this work (at least for exploration) to our backlogs.
@tauriedavis Thank you for the detailed information. Once I start the final mocks they will be super helpful.
Regarding the points that are not clear for the button placement I am attaching screenshots from the UI to clarify.
It seems that OR actions (ususally take action OR cancel) are placed spanning across the container while different types of actions are placed next to each other. In the cards however, next to each other placement works better in my opinion.
Button placement (Should we specify in Pajamas?)
spanning across the wrapper (like “create project - cancel”, “commit - cancel”,” new issue - >cancel”etc)
buttons next to each other (like “Preview - Use template”)
The re-design work for the managed apps will continue in 12.7. What do you think would be the best option: start building the components in 12.7 and the UI in 12.8 build the UI or plan all the dev work for 12.8?
@mvrachni I wanted to address this question from our team call. We discussed it briefly in the call today. We may have some wiggle room here, as updating the UI for 13.0 may be what we aim for.
Here is my proposed timeline for 12.7 and 12.8:
In 12.7, we should align our efforts with Tim and fill out a pattern library issue template within the Design Repository.
@mvrachni we discussed adding tabs to the cluster detail view and a couple other small changes to help improve this page. Do you foresee adding those ideas as part of 12.7?
@tauriedavis I am happy to work with Tim on filling out the issue template this milestone to get it ready for development in 12.8.
However, on your next point, I would like to progress with the cluster detail view redesign (tabs and other small changes) within 12.7 and, thus, I won't be able to dedicate full time to the pattern definition.
I have planned to work on ideas for the cluster page this week so that in the next week we can review and iterate on any required changes.
Maybe we should set up a meeting with you, me, and @timnoah to discuss the component to expedite that bit and then determine who can fill out the information so we ensure its ready for 12.8? WDYT?
@mvrachni@tauriedavis@timnoah I wonder if the card pattern here is actually different from the one Tim has been working on (I can't find the MR at the moment). I think this one is needed, but I worry that trying to document these as the same thing might complicate things and slow down progress. Thoughts on different card patterns for different use cases?
cc @lvanc At a quick glance I thought about the integrations work you are doing and wondered if this might be another layout option.
Its very possible we may need different types of cards. I think we need to define what a card is and then determine if we can create one flexible card that is able to handle different types of content or if multiple cards are needed. If multiple cards are needed, we should be able to define the differences. I'm not sure of the answers to these yet, it would be great to see where we are with the cards Tim has been working on in order to see how these efforts align or diverge. (I may have seen this already but I can't remember )
@jackib I had the exact same concern when reviewing @timnoah's work, but on @tauriedavis's point I think the component can be generic enough to accommodate any use case.
In my mind the interactions, actions, messaging etc are combined with the card component to form a pattern (if I remember correctly we have a term in Pajamas for the combination of components but I can't find it). In this case we can define different patterns for different card usages - UI or marketing pages.
@mvrachni This looks like a great improvement to me!
For something like Prometheus which requires a lot more configuration, how will the transition from the card to the configuration page (IIRC it's a different page) work ? Will there be a "Configuration" button ?
@tkuah I am currently thinking of expanding the card as necessary to include the configuration fields. This would be a two step interaction, where the button would first be "Configure" or "Get" and this interaction would expand the card on the same page. Having separate pages would complicate the experience and I do not think it is necessary for the default installation. I will explore designs for this and upload them in a separate issue for feedback.
I think you will also be interested in another piece of work that I have in my backlog, which will explore the custom app installation UI experience. This work will start after the redesign of the page is complete and I will be sure to loop you in for brainstorming as you are the expert :)
Interesting. @tkuah - for the configuration for Prometheus, do you mean all the settings options that are currently located off of Settings > Integrations > Prometheus (example) or something else?
If you are thinking of the options off of Settings > Integrations > Prometheus, since these configuration pieces currently live separately from the 1-click Prometheus that's installed on the Clusters from this page, I'm not sure that we'd necessarily need to worry about that here. But maybe there is some additional Prometheus configuration that it would be useful to have in the UI on this page that I'm not aware of?
At any rate, guessing we could make a follow-up issue to discuss this particular case further if/as needed, @mvrachni :)
@tkuah Is the custom app configuration going to remove the ability for 1-click installation? If not as @ameliabauerly mentioned the current default installation doesn't requires any input from the user and the configuration follows after. Is this going to change or is it an experience that can be improved?
@mvrachni I had a problem come up with "cards" on a separate issue, would this be related to your work? gitlab-design#796
@tauriedavis had mentioned that these are cards, and not a "table" in the traditional sense. My assumption is that cards are a universal component and need tweaking as a unified component.
I believe that it is related to the component design for Pajamas. We should take into consideration the types of cards in your screenshot when defining the component, as it seems we also need full-width cards.
Regarding the tables, I have also seen inconsistencies and Pajamas only defines one type of table. I saw that someone was working on tables recently, was it you? From past experience and due to the complexity of the product I believe the UI would benefit from different table patterns (e.g. default, expanding rows, expanding columns) that would be used depending on the information, interactions and use cases. I am happy to plan to work together on this in the upcoming milestones if someone else hasn't picked it up already!
I've uploaded 3 designs into the Designs tab exploring how the card layout could work using a worst case scenario with the Ingress app.
First is expanding cards. The cards are not scalable without resizing somehow, whether that is vertically, horizontally, or both. Creates visual clutter when configuring.
Second is using a modal. I read through Pajamas and one of the use cases for modals is when requiring user input, which we are here (although I'm not sure if that is limited to the primary and secondary action buttons, or if GitLab has modals with actions inside). Keeps the apps page clean by hiding inputs and options.
Last is to navigate into the app in order to configure it. I noticed in Maria's competitive analysis this is how most platforms do it. You select an application, navigate to it, then choose to configure/install. Keeps the apps page clean as well.
@mnearents consider this comment/mockup #196062 (comment 295668598) as it fundamentally changes the approach we will use here. Perhaps a sync discussion could speed up this alignment.