-
Notifications
You must be signed in to change notification settings - Fork 199
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
Remove Card from Open-UI Scope #151
Comments
Only thing I'd push back on here is that I do think certain common patterns which aren't form controls or existing elements would be valuable to create alignment on in Open UI. For instance, something like split button which is a common pattern would benefit from being part of Open UI. That nuance aside, I agree that Card doesn't make a ton of sense here. |
@una, thanks for the excellent writeup. You're touching on great points. I would like to expand the view a bit as well. I would agree that the complete scope of a card is too broad to nail down in Open UI. However, I wanted to clarify, along with Chris, that Open UI is about the UI industry as a whole coming together to define and improve common UI patterns. This includes core web HTML elements and browser vendors but it is not exclusive to them. Designers, engineers, and managers alike use Open UI today for guiding their work in a better informed and more holistic way. Because Open UI's development is based on descriptivism, we are called to document the UI patterns that have evolved in the industry. Since a "Card" is a component that is common to most design systems and component libraries, we are called to describe it with a research page at the least. Again, I would echo the original intent of the post that the contents of a card are highly suspect and not likely something we can or should define, however, let's let the research and analysis for itself. My expectation is that the high level concept of a card and its basic anatomy is something we can successfully identify. Finally, yes, it is not likely that this research page will impact the browser vendors as much as the form elements research has been. That's OK, not every corner of UI industry overlaps all the others. Sometimes, UI pattern research will affect a narrower section of the audience and that's OK. It is still tremendously helpful to the folks it does affect. I believe this is resolved but I'll leave this open for our irc discussion. Thanks again. |
This was discussed during the telecon and the resolution was to review the data and make a decision one way or another even if it means that we simply have a definition with some examples of use-cases it solves even if the anatomy can't be fully defined. |
Additional card design samples: The next few are all from this article: |
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label. |
Cards are broad components that are used for various means and describe a "View" in most cases. These take an arbitrary number of inputs, have very different interface visualizations, and are too broad to categorize as a core component. Each design system uses Cards differently depending on its product area.
Essentially, anything can be categorized as a "card", from a User Profile to an Article Preview to a Results view. I believe this group is focused on core HTML elements (such as form elements) and improving them on the web platform as generics. In that spirit, we should remove Card from the Open-UI scope.
The text was updated successfully, but these errors were encountered: