UX relating to circuitbreaker function
As a follow up to https://gitlab.com/gitlab-org/gitlab-ce/issues/33220#note_32262075, now that https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11449 has been merged, I'd like to ask our UX team to take a look at what the experience is of an NFS drive going down: if I understand correctly it will throw a 502 error to the individuals impacted. This includes anyone for whom the URL they are accessing seeks access to the downed NFS drive.
How hard would it be to do a little better than a 502, for instance populating those parts of the URL that can be populated and providing a more detailed insight into what is missing / why?
Activity
mentioned in issue #33220 (closed)
/cc: @DouweM
Not sure if this needs
UX Researchor just a UXer to take a peek at it.How hard would it be to do a little better than a 502, for instance populating those parts of the URL that can be populated and providing a more detailed insight into what is missing / why?
Once @DouweM determines what can be rendered we can take a look at how to give better feedback to the user with this information @ernstvn.
added UX and removed UX research labels
Sounds good to me. I'll add the backend label then and ask @DouweM to set priority / person ?
@sarrahvesselov What we can render really depends on the page in question. In the case of the issue display page (like this one), we may be able to render everything but the "Create a merge request" button, but the Repository page would be close to useless. The Merge Request page will be somewhere in between, depending on how much of the content is cached...
What do you want the backend to do in cases like that? Hide the unrenderable component entirely, replace it with some kind of placeholder? Show a banner of some kind at the top of the page stating that project repository data is not currently available?
I don't think it's worth designing appropriate placeholders for every component that couldn't be rendered (for every existing and future feature), since they would only be shown under highly exceptional circumstances that we always try to fix as soon as possible. Hiding components with a banner would likely be good enough.
I don't think it's worth designing appropriate placeholders for every component that couldn't be rendered (for every existing and future feature), since they would only be shown under highly exceptional circumstances that we always try to fix as soon as possible.
Agreed @DouweM. We are currently defining where and when we use our banners/empty states across the application. This is an interesting case, a bit unique since it is only certain areas of the UI that are missing. At first blush, I think it would be better not to render anything and use an empty state to explain the problem.
At first blush, I think it would be better not to render anything and use an empty state to explain the problem.
@sarrahvesselov Not render anything, not even the data that doesn't depend on the repository that we can render, like on this issue page? What you're describing sounds like the current situation, where you'd just see this error page: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/public/503.html.
Based on this description:
What we can render really depends on the page in question. In the case of the issue display page (like this one), we may be able to render everything but the "Create a merge request" button, but the Repository page would be close to useless. The Merge Request page will be somewhere in between, depending on how much of the content is cached...
I would prefer to show an empty state telling the user there is a problem than rendering half of a UI they can't interact with and slap a banner on top of it. What is the value in rendering components that, I assume, the user can not do anything with? Please correct me if I am misunderstanding the nature of the problem @DouweM.
@sarrahvesselov In the case of the issue page, everything would be fully functional, except for the "Create a merge request" button. So a user would still be able to use the issue tracker, just not anything that requires the repository to be around. I think it's preferable to enable them to use something rather than nothing.
everything would be fully functional, except for the "Create a merge request" button.
Thanks for clarifying! In this case, perhaps a dismissable message would be better. We have talked about introducing dismissable toast messages in another issue. The movement gets the users attention but the message can be dismissed or will just fade away. https://gitlab.com/gitlab-org/gitlab-ce/issues/35741
@sarrahvesselov Shouldn't we also indicate that there was supposed to be something (f.e. a "Create merge request button") but it's temporarily disabled? Otherwise it might be confusing if the user missed the toast.
Shouldn't we also indicate that there was supposed to be something (f.e. a "Create merge request button") but it's temporarily disabled? Otherwise it might be confusing if the user missed the toast
Frankly, this is why an empty state is the cleanest method IMO @reprazent. It could be just a merge button, it could be half the page is missing. Whether it is a banner, a toast, or some other component message...users may still think they can perform all functions when they actually can't. Since this is a rare and short-term occurrence anyway, I would rather give them a stand-by message.
mentioned in issue gitlab-com/infrastructure#2647
