-
Notifications
You must be signed in to change notification settings - Fork 104
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
Unify appearance of states in List, Card, and Table views #314
Comments
Research done on hover to date is here: https://docs.google.com/document/d/1ABGmLF_MxAoAGT7RFfFHukE5mjTiHzcc6CohiWOJmXw/edit |
A story has been added to the PatternFly backlog: https://patternfly.atlassian.net/browse/PTNFLY-2428 |
@kybaker can you take a look at prior recommendation and let us know whether we need a corresponding visual story. OSIO has some priority around resolving gray hover states. |
As discussed in the MGMT UX sharing on 9/11/17, maybe a simpler version of this issue is: Should the hover state on tables be blue if the rows are not interactive. |
If we go with a light-blue hover state for either list or table views as the OS console team is selecting, we will need a different selected state for list view rows. I'm not entirely sure what the right answer is but agree this needs to be simplified. I have assigned this to myself and will try to articulate some options that can be reviewed. |
I did some analysis on this to look at how we are representing state across the three primary content views (card, list, and table). @jennyhaines helped me by doing some quick mockups to explore some options. You can see this summarized here: https://docs.google.com/a/redhat.com/document/d/1qoAetrAZVVEFq8so2tlkP7eRJaCkITskooOMV4LjxzI/edit?usp=sharing In short, the proposal is to use a slightly lighter blue for the hover state on list view (replacing the gray). This promotes consistency while maintaining enough differentiation between hover and selected states for the list view rows. @kybaker can you review and let us know if you approve of this approach? If so, this issue can be resolved by simply changing the hover state color on list view (we might also consider using the same RGB for hover on table view, but I don't think that's critical). |
This will be queued up for implementation. @jennyhaines we will need the RGB values of the lighter blue color to use for the list view hover state. Thanks again for your help! |
@mcarrano @jennyhaines The lighter blue looks good to me. |
@zhutaoredhat will make updates to the design documentation to reflect this. There is a PatternFly story created here: https://patternfly.atlassian.net/browse/PTNFLY-2553 @jennyhaines can you communicate the RGB you used for this to make sure we get this right? @andresgalante will be updating CSS styles to make sure we keep this in sync. |
Hi @mcarrano - The hex for that hover state light blue is #edf8ff |
Hi @jennyhaines that color is not on our color pallet: https://www.patternfly.org/styles/color-palette/ If it's ok with you I'll create a PR with pf-blue-50 |
Hi @andresgalante - So does that mean that the selected (non-hover) state is #bee1f4 , and the hover state would be #def3ff (one tint lighter in the color palette)? If yes, I'm all for it! |
@jennyhaines it'd be the same color active and hover :( What about the new list? https://rawgit.com/patternfly/patternfly/master-dist/dist/tests/list-pf.html @mcarrano Should it follow the same blue? I think that if we change it, it will break OpenShift |
I'm a little confused about this question @andresgalante . I though that we were changing from gray to blue on hover per the request of the OpenShift team. Is that not the case? |
@mcarrano me too. So, let me know what to do and I'll do it. We have 2 types of lists and @jennyhaines is proposing a color that is not on our color pallet. I can absolutely change it if you think that's ok. I am just pointing out what I am required to do so we are all aware of the consequences. |
I'll defer to @kybaker and @jennyhaines on the exact color and whether we need to add this as a new color to the palette. |
@andresgalante @mcarrano IMO, the color doesn't need to be added to the palette since it is really the only case I can see us needing it in our patterns, but I'm curious what Kyle thinks. I think that just setting the hover state to #edf8ff would work great. |
I would suggest adding it to the palette. Applications may want to reference the same value to be consistent in other instances. |
@jennyhaines @andresgalante @mcarrano I agree with Jeff here. The cost of adding it is outweighed by the potential for promoting consistency. We should add it. @mcarrano can you add a story for updating the color palettes and the CSS to reflect this change? |
I'll close this issue since this PR is open patternfly/patternfly#798 |
Fixes openshift#1904 Until patternfly/patternfly-design#314 is addressed, I think we should avoid using .table-hover in our tables.
Fixes openshift#1904 Until patternfly/patternfly-design#314 is addressed, I think we should avoid using .table-hover in our tables.
Currently there is inconsistency between hover, selected, and disabled states for list, card, and table views. These should be made more consistent.
The text was updated successfully, but these errors were encountered: