UI Tweak: Consistent text inputs #3234
Assignees
Labels
area/ui
kind/design-spec 📐
Design specification document
kind/enhancement ✨
Issue for requesting an improvement
Comments
mairin
added
kind/enhancement ✨
|
Could you give an example of user entered text that is not-active/disabled, or confirm the color? Not clear to me if it should remain white, dim to the same level as default (placeholder) text, or stay somewhere between. |
Oh sure. I updated the screenshot in the issue description with color names (from top to bottom, (1) accent/border line, (2) text /icon color, (3) input background color). Let me try to think through the case... so the user navigates to a text field:
They hover over it: They click into it which focuses it (border color is slightly darker): They start typing and the default text is replaced with the text they enter, and their new text is white while the field is active & focused: So I think what you're asking is what happens to the text when the user removes focus from this text input to elsewhere, making this text input inactive, right? I would say the user-entered text should stay white, but since the field is inactive, it goes back to that non-rounded, single bottom accent line color version like this:
Does that make sense? |
|
Yup, that does. How about if the user text gets disabled? e.g. Proxy settings today you can enter values and then disable the whole form. |
I would just use the same styling as disabled.... because I think the fact that the field is disabled overrides whether or not the user entered text into it, and I'd not want to muck with the coloring too much on that to call into question whether or not it's really disabled. |
|
Here's a link to the penpot file for this: |
deboer-tim
added a commit
that referenced
this issue
Feb 8, 2024
Creates a new Input component with the same basic support as an HTML input, but with our styling. Supports 4 types so far: - normal text - search (adds a search icon on the left) - clear (adds an X on the right, which clears the field unless the parent event handler overrides it) - password (with a show/hide button on the right ( unless the parent event handler disables it) I don't want to give any impression that this component is fully done or supports all cases, my intention is to get a good base component that does enough to support the initial use, then expand it as necessary to support different uses or additional style requirements. In order to give something to test, the first few uses of Input are included: - Main nav page search bar - Settings > Preferences search bar - Settings > Preferences string and file items First step of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
Merged
deboer-tim
added a commit
that referenced
this issue
Feb 8, 2024
Creates a new Input component with the same basic support as an HTML input, but with our styling. Supports 4 types so far: - normal text - search (adds a search icon on the left) - clear (adds an X on the right, which clears the field unless the parent event handler overrides it) - password (with a show/hide button on the right ( unless the parent event handler disables it) I don't want to give any impression that this component is fully done or supports all cases, my intention is to get a good base component that does enough to support the initial use, then expand it as necessary to support different uses or additional style requirements. In order to give something to test, the first few uses of Input are included: - Main nav page search bar - Settings > Preferences search bar - Settings > Preferences string and file items First step of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 8, 2024
Creates a new Input component with the same basic support as an HTML input, but with our styling. Supports 4 types so far: - normal text - search (adds a search icon on the left) - clear (adds an X on the right, which clears the field unless the parent event handler overrides it) - password (with a show/hide button on the right ( unless the parent event handler disables it) I don't want to give any impression that this component is fully done or supports all cases, my intention is to get a good base component that does enough to support the initial use, then expand it as necessary to support different uses or additional style requirements. In order to give something to test, the first few uses of Input are included: - Main nav page search bar - Settings > Preferences search bar - Settings > Preferences string and file items First step of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Creates a new Input component with the same basic support as an HTML input, but with our styling. Supports 4 types so far: - normal text - search (adds a search icon on the left) - clear (adds an X on the right, which clears the field unless the parent event handler overrides it) - password (with a show/hide button on the right ( unless the parent event handler disables it) I don't want to give any impression that this component is fully done or supports all cases, my intention is to get a good base component that does enough to support the initial use, then expand it as necessary to support different uses or additional style requirements. In order to give something to test, the first few uses of Input are included: - Main nav page search bar - Settings > Preferences search bar - Settings > Preferences string and file items First step of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when creating a volume. Bonus fix: button should be disabled until the volume has a name (if I don't pick a name, UI hung). Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when installing Podman or Docker extensions. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
This was referenced Feb 9, 2024
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when creating a pod from containers. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when creating a volume. Bonus fix: button should be disabled until the volume has a name (if I don't pick a name, UI hung). Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when creating a volume. Bonus fix: button should be disabled until the volume has a name (if I don't pick a name, UI hung). Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when installing Podman or Docker extensions. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 9, 2024
Use the Input component when editing registries. Switching to use Input and PasswordInput I had to clean up some styling and 'use:' code. Found two minor things needed for the components: - Input needs to have overflow-hidden to work in narrow spaces. - Password was missing a placeholder. While testing I found *lots* of UI issues that are unrelated to this change. None of the columns/sections are aligned, have different spacing/styling/padding or none between user/password/button columns, sometimes controls touching each other, etc. I have another PR ready to go, but am keeping this one limited to just the input component change to keep things separate. Another small part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 10, 2024
Use the Input component when creating a pod from containers. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 11, 2024
Use the Input component when configuring a proxy. This is the first control to require disabled inputs, so that support is added here - from the design it is the same as readonly except user text is the same color as placeholder text. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 11, 2024
Use the Input component when configuring a proxy. This is the first control to require disabled inputs, so that support is added here - from the design it is the same as readonly except user text is the same color as placeholder text. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 11, 2024
Use the Input component when editing registries. Switching to use Input and PasswordInput I had to clean up some styling and 'use:' code. Found two minor things needed for the components: - Input needs to have overflow-hidden to work in narrow spaces. - Password was missing a placeholder. While testing I found *lots* of UI issues that are unrelated to this change. None of the columns/sections are aligned, have different spacing/styling/padding or none between user/password/button columns, sometimes controls touching each other, etc. I have another PR ready to go, but am keeping this one limited to just the input component change to keep things separate. Another small part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
benoitf
pushed a commit
that referenced
this issue
Feb 12, 2024
Use the Input component when configuring a proxy. This is the first control to require disabled inputs, so that support is added here - from the design it is the same as readonly except user text is the same color as placeholder text. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 13, 2024
Use the Input component when configuring a proxy. This is the first control to require disabled inputs, so that support is added here - from the design it is the same as readonly except user text is the same color as placeholder text. Fixes another minor part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 13, 2024
Use the Input component when building an image. Fixes another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 13, 2024
Uses the Input component in the Run Image form. This is the first time that we have inputs with 'errors', so I've added support to Input for an error. When there's an error the purple changes to red, there's a red X on the right, and the error message is listed underneath the input. Another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 13, 2024
Use the Input component when building an image. Fixes another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 14, 2024
Uses the Input component in the Run Image form. This is the first time that we have inputs with 'errors', so I've added support to Input for an error. When there's an error the purple changes to red, there's a red X on the right, and the error message is listed underneath the input. Another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 15, 2024
Use Input component when deploying Pods to Kubernetes. Fixes another small part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
Feb 15, 2024
Use Input component when deploying Pods to Kubernetes. Fixes another small part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
|
A progress update: the Input component is in, along with customized SearchInput and PasswordInput components. These support the majority of inputs, and over 45 uses have been switched over to the new components. There are 7 places that still use a regular text/number (a couple of which might not need to change):
Given the number of places where we have an Input + Browse button, we will also need to create a composite FileInput. |
1 task
deboer-tim
added a commit
that referenced
this issue
May 8, 2024
The current number editor in Settings > Preferences works, but it has a few drawbacks: - doesn't match current design, and would need updating to light mode. - periodically has some odd 'resets' to a previous number. (this isn't just the input - figured out later this is #7142) - has two error modes - underline for below minimum, icon to the left for invalid value. - after invalid entry (e.g. below minimum), incrementing does a string add vs numerical. - not easily reusable for editing numbers in other places. This creates a NumberInput component that is just an Input with +/- buttons. Key input is restricted to numbers, and increment/decrement are used to disable +/- appropriately. If the user manually enters a number out of bounds, the Input's error is used to display a short warning. Input required some minor changes to support this: - allow inputClass in order to center numbers in the textbox. - passthrough of key events, in order to block non-numerical entry. - boolean to block showing the error in a separate span. Although this is the design for inputs, it felt really out of place in preferences. - reduce padding slightly - it didn't matter in large Inputs, but number inputs tend to be smaller and extraneous padding was obvious. New component is used in Settings > Preferences and max retry count for running an image. Tests added. NumberItem test had to be changed since only numerical inputs work now. Another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
May 8, 2024
The current number editor in Settings > Preferences works, but it has a few drawbacks: - doesn't match current design, and would need updating to light mode. - periodically has some odd 'resets' to a previous number. (this isn't just the input - figured out later this is #7142) - has two error modes - underline for below minimum, icon to the left for invalid value. - after invalid entry (e.g. below minimum), incrementing does a string add vs numerical. - not easily reusable for editing numbers in other places. This creates a NumberInput component that is just an Input with +/- buttons. Key input is restricted to numbers, and increment/decrement are used to disable +/- appropriately. If the user manually enters a number out of bounds, the Input's error is used to display a short warning. Input required some minor changes to support this: - allow inputClass in order to center numbers in the textbox. - passthrough of key events, in order to block non-numerical entry. - boolean to block showing the error in a separate span. Although this is the design for inputs, it felt really out of place in preferences. - reduce padding slightly - it didn't matter in large Inputs, but number inputs tend to be smaller and extraneous padding was obvious. New component is used in Settings > Preferences and max retry count for running an image. Tests added. NumberItem test had to be changed since only numerical inputs work now. Another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
deboer-tim
added a commit
that referenced
this issue
May 10, 2024
The current number editor in Settings > Preferences works, but it has a few drawbacks: - doesn't match current design, and would need updating to light mode. - periodically has some odd 'resets' to a previous number. (this isn't just the input - figured out later this is #7142) - has two error modes - underline for below minimum, icon to the left for invalid value. - after invalid entry (e.g. below minimum), incrementing does a string add vs numerical. - not easily reusable for editing numbers in other places. This creates a NumberInput component that is just an Input with +/- buttons. Key input is restricted to numbers, and increment/decrement are used to disable +/- appropriately. If the user manually enters a number out of bounds, the Input's error is used to display a short warning. Input required some minor changes to support this: - allow inputClass in order to center numbers in the textbox. - passthrough of key events, in order to block non-numerical entry. - boolean to block showing the error in a separate span. Although this is the design for inputs, it felt really out of place in preferences. - reduce padding slightly - it didn't matter in large Inputs, but number inputs tend to be smaller and extraneous padding was obvious. New component is used in Settings > Preferences and max retry count for running an image. Tests added. NumberItem test had to be changed since only numerical inputs work now. Another part of #3234. Signed-off-by: Tim deBoer <git@tdeboer.ca>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your enhancement related to a problem? Please describe
There's some variants in how we use text inputs and we have some standalone ones. (For instance, right now when active on the text input on Desktop Extensions is a white border, whereas on the preferences search text input the active version has a purple border.) The color palette for these I don't think is 100% consistent either.
Describe the solution you'd like
Here is a spec for creating a consistent component for text inputs (including search text inputs.)
https://design.penpot.app/#/view/8ec95363-4e2c-80a4-8002-cb67c874d0be?page-id=42e69059-b409-807e-8002-d0b98cda8446§ion=interactions&index=0&share-id=c65f3168-697c-808c-8002-d0c926187cdf
Via the link above, make sure you click on the </> icon at the top/center of the page, and you can inspect individual elements like so:
Posting screenshot of the spec above, but the penpot link above will always have the most updated/latest, these are a snapshot in time (updated 17 Jul 2023):
The text was updated successfully, but these errors were encountered: