Skip to content
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

UX issue with ghosted values in fields #3847

Closed
ccallawa opened this issue Jul 8, 2019 · 3 comments · Fixed by #3911
Closed

UX issue with ghosted values in fields #3847

ccallawa opened this issue Jul 8, 2019 · 3 comments · Fixed by #3911
Assignees
Labels
area/ui Affects the user interface bug Something isn't working
Milestone

Comments

@ccallawa
Copy link

ccallawa commented Jul 8, 2019

Describe the bug

Grayed out (ghosted) text in fields can be interpreted either as defaults or examples.

To Reproduce

  1. Go to Configuration > Modules > monitoring > Security
  2. For "Protected Custom Variables", the "pw,pass,community" string is shown in gray if it has not been configured

Expected behavior

It should be more clear whether it is an example or a default. My suggestion in this case is that you should see "Ex: pw,pass,community" so the user knows it is an example. Without the "Ex:" it might be a default value.

Your Environment

  • Icinga Web 2 2.6.2
@ccallawa
Copy link
Author

ccallawa commented Jul 9, 2019

Updates:

  • The official documentation does not mention that the regex is case insensitive
  • The phrase "string patterns" sounds like it's a regular expression, but it seems that * is the only operator available
  • The standard definition of "Comma separated list" allows for optional spaces after the comma. If you use them here, they are included as part of the string pattern.

I think the above are important because if you are unaware of these limitations, the result is failure to hide a password, which is a security problem.

For the UX issue, I think you should use a tooltip like this attached screenshot to explain the details.
example-gui-director

@lippserd lippserd added this to the 2.7.1 milestone Aug 5, 2019
@lippserd lippserd added area/ui Affects the user interface bug Something isn't working labels Aug 5, 2019
@lippserd
Copy link
Member

lippserd commented Aug 5, 2019

Adding something like "Example: " to the placeholder absolutely makes sense.
But should we also change the styles of our placeholders @flourish86?

[1] Placeholder

Screenshot 2019-08-05 at 13 19 22

[2] Real value

Screenshot 2019-08-05 at 13 19 35

@flourish86
Copy link
Contributor

flourish86 commented Aug 5, 2019

Maybe setting placeholder in italics would help to distinguish it better from real values. If we do this globally for placeholders, this should be recognizable to users after some time.

Introducing a prefix like »Ex: « or »Example: « would require us to do that for every input placeholder for consistency reasons.

That would make input crowded views confusing. Users would get fatigued to read the placeholders because of the repetitive prefixes (esp. with the longer »Example: «.

I'd rather opt for a distinctive style (like grayed italics) for all input placeholders, which is consistent throughout the UI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ui Affects the user interface bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants