-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need a good way to alert users about why they can't use certain functionality (eg. bc of permissions) #1912
Comments
You need |
@roxy-dao @mark-prins do we have a preferred pattern for things that are prevented because of permission? I think adding at least a tooltip could be helpful here. |
Already has a tooltip 😉 I don't like the alert on an enabled button, it means I have to click to dismiss the alert. The disabled button is a good visual cue that it isn't allowed. That's personal preference though I guess. |
🤔 I noticed people don't actually use the tooltips at all... Maybe a pain to hover over things all the time to see if there is a tooltip of not? Maybe they don't know there's a tooltip? 🤷🏻 |
Hahha yeah I was trying to find definitive articles telling me what was the best way. I started out neutral between "disabled and tooltip" and "enabled and alert" and then I started leaning towards enabled: I'd (1) agree with Roxy that lots of people don't hover (not everything has a tooltip), (2) want to suggest we ask @anisha-msupply when she gets back (even though I now feel very strongly about my new opinion), (3) should have this consistent across omSupply and HSH |
One more link: https://uxpsychology.substack.com/p/hidden-vs-disabled-states |
I like the click + toast option - can that work even if the button is disabled? |
The button would not be disabled for click + toast option 🤔 ... though the other disabled buttons would need to be refactored for consistency? Click + toast sounds good to me. |
Let's leave this for when @anisha-msupply is back, and then have the decision communicated across all our products - might be good to have a guideline in Storygraph. |
Also disabled with a question mark that is clickable |
Anisha says: Button enabled and toast |
TODO: Document where needs to be updated to match this behaviour |
Hey @DhanyaHerath, I'm wondering that given Anisha's input, is this still requiring discussion? |
I'm also wondering if you're needing any more actions to get this into HSH design pipeline? |
Absolutely agree - having to click away alerts like that is one of my pet hates about desktop mSupply - personally I prefer some visual cue e.g. different colour/style/disabled button + a tooltip, but toast is also ok as you don't need an extra click. You just need to be patient for the short time it takes to disappear again, although that might be a problem for some :-) The same goes for mandatory fields, particularly if there are multiple ones - there should be a clear visual cue. There are few things more annoying that having to go back and fill in one field, click OK and then be told that you've missed another one... |
Have implemented the callout version, as per this comment I still like the toast though, so I'm thinking I may change to that |
🧪 TestingTested in omSupply You may need to turn off permissions and then login again in order to properly test. I tweaked the code bc I'm lazy.
|
Found Issue here #5223 |
What went wrong? 😲
In latest
v1.1.15
apk, theConfirm sent
button is disabled and thus the internal order can't be send anymore!Let know if I'm missing any new updates/changes in the flow! (since it was working well in
v1.1.14
) 🤷Expected behaviour 🤔
The
sent
button should not be disabledHow to Reproduce 🔨
Steps to reproduce the behaviour:
Confirm sent
button is disabledYour environment 🌱
Solution:
"Anisha says: Button enabled and toast"
The text was updated successfully, but these errors were encountered: