With the introduction of assigning multiple compliance frameworks to a project, the framework labels on the project listing pages need to be updated to show multiple frameworks.
Proposal
Remove the framework labels from the project listing and single project page, that is next to the project name.
In its place introduce a shield icon, with a popup that displays the assigned frameworks. Include a button to redirect users to the framework report in compliance center.
@cam.x!
Hope you are doing good!
I've just noticed that we are already using the Shield icon in the project/project overview pages to show that a project is Internal.
Were there any other ideas regarding the icon which can represent the frameworks info?
Or how do you think is the best to approach the problem?
@cam.x great! Thank you . I think for now I will still continue to work on the issue since changing the name of the icon is a very small change anyway and is not blocking me much.
Thanks for raising the topic in the UX channel @cam.x
I will repeat the idea I posted in Slack here:
Currently, we are using a label for a single Compliance framework. Maybe it is also an option to use the label “Compliance frameworks” or “Compliance info” with a popover for multiple frameworks?
Hi @nrosandich@khornergit , here is the most recent idea based on @nradina 's idea, I am still collecting feedback from the UX channel, and also from yours as well ;) I will let you know when the design is done.
@cam.x My only feedback would be Compliance frameworks applied is very long and potentially distracting. I prefer an icon but understand if not possible
Thanks @cam.x - my feedback is similar. Would prefer an icon since the phrase is too long. However, if we can't find a suitable one, happy to go with this as an MVC approach first, before thinking of what icon we can use in the long term to swap out the long phrase
@khornergit@nrosandich Thank you for the feedback. The concern with the icons is also that we don't know whether users already associate the shield with the concept of an internal project. The best way is to use the label with words and switch the current shield icon to something else. Let the users get used to the new icon with the concept internal project. And later update the compliance with icons.
What do you think the word compliance instead of compliance framework applied ? Maybe @eread can help us with coming up with some ideas?
@eread To summarise, we want to show in the project overview that the project has a compliance framework applied because we are going to have multiple compliance frameworks; showing them all is not an option. So, the idea is to have a label with words to tell users this project is being covered by several compliance frameworks. Details show in an popover
As another thought could we potentially create a new icon for compliance? As the shield is used for all of Secure, I wouldnt want to "steal" it from other use. Maybe something like a project or doc-text with a shield in the bottom right?
@cam.x - thanks Cam, I think the suggestion to use the word compliance works. I would prefer us to use a new icon, however if that takes longer to implement due to needing to create something from scratch + discussions with the wider design team, then I would prefer speed in this instance and just use the word compliance if that's quicker and easier Thanks
We try to avoid using generic label icons to avoid confusion between the compliance framework and labels. I am contacting the foundation team to see if we can have a new icon done at this milestone.
If we're limited to a single word, we almost want to say complianced I almost want to suggest compliance info, but I don't really like info.
In case we can't really point to a suitable icon, is Complianced our best word choice so far?
@nradina Thank you! Requirement is a candidate. Could you do a quick search in code to see if we use it anywhere? If not, we use it for now. I also created a new issue for a compliance icon.
@cam.x that's a bit tricky, because overall the word 'requirements' is used quite often. But I haven't found any occurrence of the icon in .vue or .haml files.
@eread I can't easily check if it is used somewhere or not because the word "requirements" is quite popular in the codebase. @cam.x may be this is something which can be checked in the UX channel?
@nradina@eread Thank you for the discussion! There is an extra thread confirming this with the DRI in the issue, but based on the Slack discussion. Seems like we can go with
Shield icon for compliance
Building icon for internal
I have updated the design in the description. It means there is extra work to do to change the icons for `internal`, @nrosandich. This needs to be done. I am not sure if we do it, or do we collaborate with developers from the group: manage?
@cam.x What is the extra work needed? How many times is the internal badge used? As we have a tight timeframe for releasing this in 17.2, I think we will have to do this to expedite it.
@cam.x Looking at the internal thread I do not see a decision on this?
@nrosandich Let's wait for Mike on this thread with a definite agreement. I also had a DM chat with Nick initially, and we both think swapping is best. then realized that Mike was the DRI.
@nradina To be safe, Let's just wait for @mnichols1's answer in the thread (He is in the US timezone); to go with the shield, we need to change the other one first. Otherwise, we will have two shields in the product. So we need the team to be on board with the solution :)
@cam.x yes, makes sense! But then I probably already can use the shield icon in the adherence table at least. I already asked you to review my MR with it.
@cam.x just couple more questions to make sure I understand everything correctly:
I see the close button in the popup. Does it mean that we show the popup only on click and not on hover?
The labels of the frameworks are not interactive - they simply display the Name with the color, but do not have any actions like redirect to some page etc.
I see the close button in the popup. Does it mean that we show the popup only when clicking and not when hovering?
Yes, a popover is always triggered by a click based on our guidelines.
The labels of the frameworks are not interactive - they simply display the Name with the color, but do not have any actions like redirect to some page etc.
Yes, they only display because there are edit/view rights issues (not everyone can view or edit the compliance framework labels). So we are limited, that is why we introduced the button. The button is enabled or disabled based on user rights. We can't disable or enable a label. I hope this is clear. I am happy to explain more if needed :)
@nradina This issue looks like it may slip this current milestone. Can you leave a or to signify if you are on track to deliver this issue?
Please also consider updating the issue's Health Status or Milestone to reflect its current state,
and communicate with your Product Manager as appropriate.
@mnichols1 To save you time on the threads, here is the summary:
we will introduce the ability to link many compliance frameworks to 1 project. And on the project page, we must hide framework labels under an icon. We originally chose the shield icon, but @nradina detected it is used for internal. I think `shield` icon does not reflect the concept of internal. So here are the options.
I prefer option 2. Because Shield still communicates security and compliance the best. I was talking with Nick in slack, but then I realized you are the DRI. So look you in here ;) Let me know what you think!
1 Use a word
2 use the shield for compliance and building for internal
3 use the building for internal and requirements for
Not ideal because it becomes a really long
Risk: does the user associate shield with internal?
The requirement icons look very similar to issue type
@mnichols1 Follow up on the Slack question. Yes, we will do both the list and detail page. It seems like we agree on Option 2: swap the icon. Could double check? Sorry for the multiple messages, this is a high priority for us, and we only realized that the shield is in use during development.
I have changed the descriptions. Let me know if you have further quetions.
And on the project page, we must hide framework labels under an icon
I understand the need to introduce a method to display multiple compliance frameworks, but I am not sure I agree that this needs to be hidden under an icon. An icon requires a lot of user understanding to be valuable. Have you considered other patterns? On the project details page, there is a section on the right for project information, it could fit nicely into there.
On the list page, will knowing the existence of a compliance framework help the user find the project they are looking for? If not I am not sure it needs to be included. The list page's primary function is to assist users in finding projects. This feels like it might be better suited for a filter.
As to the shield icon, it has been in the product with the meaning of internal for a very long time and as such likely developed some meaning for users. Changing it now would require almost every user to have to relearn this pattern and it is not something I would recommend. Also, note that the icon is used in several other places than just the project list and details pages. It appears a lot of places in settings and applies to groups as well. My fear is this change is going to have a much larger impact than intended.
An icon requires a lot of user understanding to be valuable. Have you considered other patterns? On the project details page, there is a section on the right for project information, it could fit nicely into there.
On the list page, will knowing the existence of a compliance framework help the user find the project they are looking for? If not I am not sure it needs to be included. The list page's primary function is to assist users in finding projects. This feels like it might be better suited for a filter.
@mnichols1 The use case on the list and the detail page allows users to see if this project is covered by compliance quickly. We have a compliance center that the user uses to find projects. It is more servers like a scanning hint rather next steps or something.
As to the shield icon, it has been in the product with the meaning of internal for a very long time and as such likely developed some meaning for users. Changing it now would require almost every user to have to relearn this pattern and it is not something I would recommend. Also, note that the icon is used in several other places than just the project list and details pages. It appears a lot of places in settings and applies to groups as well. My fear is this change is going to have a much larger impact than intended.
@mnichols1 I understand It takes time for the user to get used to changing an icon. The shield icon is used in our main navigation, and it is also a more potent metaphor to connect the shield to a secure/compliance feature. I think we should limited the shield to compliance/secure regardless of this issue.
@mnichols1 What do you think change use of shields from the concept of `internal` to `secure/compliance` cross the whole site? It could be done in a separate issue. ( #466665) In this way, we have a consistent message for the shield icon and clears our way for the future.
As for the solution to this one, there is another option: we will not show it anymore on the list and detail page. @nrosandich@khornergit We have discussed this before. We chose to use icons because we think this is a good MVC, but now we don't really have a good icon or word label. I think it is best we remove it because most users' main tasks related to compliance will be done in the compliance center. When we have a good "visual hint" related to the compliance concept, we can add it back. I also created an issue to create a new icon for compliance purposes in the future, but I don't think it will be done within 17.1. What do you all think?
@cam.x I agree with @mnichols1 that we should not just change icons that our users have grown accustomed to for many years:
As to the shield icon, it has been in the product with the meaning of internal for a very long time and as such likely developed some meaning for users. Changing it now would require almost every user to have to relearn this pattern and it is not something I would recommend. Also, note that the icon is used in several other places than just the project list and details pages. It appears a lot of places in settings and applies to groups as well. My fear is this change is going to have a much larger impact than intended.
We already receive the feedback quite often that UX changes are too frequent, and that we are putting a lot of burden on users to adapt to these changes. I also wonder if the compliance information is something that really needs to be exposed to all users, or whether a specific persona, such as an admin or top-level group Owner would be mostly interested in this information. Project visibility is something that affects every user, as they need to understand who can access group or project content. It seems like a much easier change to adapt the shield icon in the context of Secure as a navigation element, instead of updating the visibility icon, which is used in many different places (the group and project list pages, group and project overview pages, group and project settings pages and Admin Area are just the immediate ones coming to mind), and would put the burden on grouptenant scale to adapt to this change, which we don't have capacity for at the moment. Also, be mindful that users might continue thinking the shield represents internal visibility, as that is the icon they are used to and they might miss that the meaning has changed, and they might make decisions based on that, which could then become a security risk. In the worst case they might expose information that they weren't supposed to because of that, which is something we should be really careful about.
The use case on the list and the detail page allows users to see if this project is covered by compliance quickly. We have a compliance center that the user uses to find projects. It is more servers like a scanning hint rather next steps or something.
Have we validated quickly that scanning is a needed enough use case to justify adding clutter to the list? What % of users would find value in this vs having to endure extra clutter? Seems like if there is a compliance center, that would handle that use case and allow us to not further clutter the list. I get the concept, but the project list page can not handle every use case without becoming overly cluttered. I think filters is a better pattern for the list.
To add to @lohrc point above. I don't disagree that the icon is a good representation, my concern is with disputing an established pattern. This becomes especially true when the icon will be in the same position. This could be very confusing.
Have you involved a maintainer of SVG project, this feels like a significant enough change that someone should be involved. @jeldergl going to tag you for awareness.
Thanks @mnichols1. It's not clear to me how a shield represents a framework and should be used for Secure. I'm not sure if I'm missing something from the threads here though.
We chose to use icons because we think this is a good MVC, but now we don't really have a good icon or word label. I think it is best we remove it because most users' main tasks related to compliance will be done in the compliance center.
Seems like if there is a compliance center, that would handle that use case and allow us to not further clutter the list
@cam.x@mnichols1 the compliance center is limited to only top level group owners and maintainers. Without some indication of the compliance frameworks applied to a project, project users have no way of knowing why there is compliance settings/policies affecting their project. I think it is critical information.
I get the concept, but the project list page can not handle every use case without becoming overly cluttered.
Currently the framework is listed on both of these pages, with a bright coloured label. Now that we are moving to multiple frameworks, instead of simply adding more clutter to these pages we thought best to hide behind an icon. Removing some of the current clutter.
@cam.x Instead of an icon for the project page we could move this to the section on the right side, for project information?
Maybe we could remove from the project list page and look to add back later once we have a defined icon?
Thanks all for the thoughts shared here. If I could summarise what I think everyone has a concensus about, it looks like the following:
We agree that there should be a method or way by which we indicate when a particular project has a compliance framework applied to it;
We agree that having some sort of icon to do this is a good idea;
However, we disagree that it should be the 'shield' icon, as this has been used before and internally means 'internal'; and
This may involve a large context change for lots of our users, especially those that may not use compliance frameworks as part of the product
I do agree that it's best to find an icon. If the reasons for not using the shield icon is valid, then I agree that it will represent a context change for our users. I would be in favour of using a new icon if we could, that doesn't have any legacy understanding behind it and can be used by secure/govern moving forward to denote when a compliance framework is used.
However, we still have to solve the problem of being able to inform the user that there is a compliance framework attached to a project on the project list, as this is existing functionality that we don't want to remove and an icon works best. I'm happy to follow @nrosandich's suggestion above, as long as there's a fast follow up to ensure we get a new icon in a future milestone, which we can chat about for future work @cam.x
@lohrc@mnichols1 Regarding how we should use the shield icon in the future, I will follow up on a separate issue. I understand the impact of changing an icon, but I also have concerns if we don't make a decision about what a shield icon is, we will confuse users in the in the future, and it will hurts us in the long term.
@nradina, I think we have space for the adherence list. Let's use a label. I will update the description until we have a new icon. Thank you for keeping up with me about the back-forth changes! Appreciated!
This is just for everyone's context. After having a sync call with @nradina , it is probably best to wait for the issue: gitlab-svgs#419 (comment 1946844570) to avoid double work on implementing this.
@nrosandich The only thing is that we should address this issue together with the settings change, which allows users to apply multiple compliance frameworks to one project. The situation that we don't want to get is that.
The user applies three compliance frameworks to a project. And we only show one in the project and adherence list.
To be safe, shall we make this change and apply many compliance framework settings under one feature flag to make sure they are released together? So, to prevent a confusing situation?
we can also make sure that we do things in the right order:
@nradina, Sure thing! It is up to you and @nrosandich to decide how to implement it. I just provide some thoughts, in case No.3 will go faster than No.1&2. I am happy to follow up on your decision for implementation
My reasoning here is that removing the badge from the list view right now doesn't add any value because possibility to add multiple frameworks is not implemented yet.
But if we think that making the new icon will take a lot of time and we might be able to allow users to add multiple frameworks before that happen - may be we might remove the badge for now.
Also question to @nrosandich if this is something confirmed and ready for dev - #462942[On_details_page.png] ? And just out of curiosity - if yes, will it be also temporary before the icon made or is it something we will stick to.
When new icon is ready update the project list page with icon/popup
@cam.x In item 1, why can't we update the project list page with single label with popup, the same as item 4? Since we will update with icon later?
The only thing is that we should address this issue together with the settings change
Im not sure I understand the issue here? The backend work is scheduled to be released in 17.2. Based on the above plan we should be able to release the frontend first? This would remove any issues?
@cam.x In item 1, why can't we update the project list page with single label with popup, the same as item 4? Since we will update with icon later?
@nrosandich I am afraid that not every user will hover on the label to see the details. We have given hints that there is not one compliance framework; there are many. It will create confusion for users, "I added multiple, why is it only one?" Hope this makes sense.
The only thing is that we should address this issue together with the settings change
Im not sure I understand the issue here? The backend work is scheduled to be released in 17.2. Based on the above plan we should be able to release the frontend first? This would remove any issues?
I am trying to see what has the lowest impact on users, which means the less change users see, the better.
If we don't have the ability to have multiple compliance frameworks yet, there is no need to release No.1 (Remove compliance framework on the project list page) and No.3 (Update the adherence report to a single label with popup)
If we get the icon done in 17.2, we don't need to release No.1
@nradina also raised the point that she doesn't need to switch back and forth between icons and removing labels. I didn't come up with a good order. That's why I thought of putting N0.1 and No.3 together with the "ability to set multiple compliance framework settings" behind one feature flag. I hope this is clear.
@nradina This issue looks like it may slip this current milestone. Can you leave a or to signify if you are on track to deliver this issue?
Please also consider updating the issue's Health Status or Milestone to reflect its current state,
and communicate with your Product Manager as appropriate.