I feel like many commenters didn't bother to give 2 minutes to check out the site to get the gist of it. Sure, on first glance it does look like Yet Another design system or an alternative to Storybook, but in fact it's something else. This is sort of a wiki for common UI components, i.e., there's information on when to use them, how to implement them, common gotchas, and so on. Since using a 3rd party design system is not feasible for many businesses, I think this has the potential to be a great resource.
I think author wouldn't have this problem if they wrote "Best practices for common UI components" instead of "The documented collection of UI components" as the header.
After my first experience with design systems, I decided to kickstart a project called UI Playbook which is my attempt to document common UI components, their functionality, best practices, accessibility requirements, and examples.
If at least one person finds this useful — it's a win!
What's your general thought on adapting one of the bigger design systems with thousands of hours of improvement & polishing vs building one from scratch?
I do think there is need for a common vernacular in these components, however I think that too often teams start from scratch when they could pull something off the shelf, and swap out some colors.
At some point you’re fighting against the design system more than you’re using it. It’s The same reason that I wouldn’t build a web app on WordPress. WP is great if what you want is a WordPress site. Otherwise, you’re just trying to shoe horn _your app_ into WordPress. Most of these things aren’t difficult to build and can be picked up a la carte and customized to whatever extent.
The depth & flexibility in many of these libraries is quite extraordinary.
Totally agree with the Wordpress example, however, I'd argue that more products & applications should attempt to be build upon known primitives to reduce cognitive overload for both the building team and the end users.
Agree with this comment. I think it is awesome that OP worked on a design system for the first time, that’s great experience to have, but it doesn’t warrant further diluting the market with another unfinished system.
Oh, then I guess I don’t see the point? Actual design systems vary quite a bit, refer to their documentation for their exact flavor of how to implement UI correctly and eliminate the middleman. I’m not saying having a general knowledge of the underlying tools is bad, that’s great knowledge to have, but it does already exist if you look for it.
If I had to guess, the point is that OP enjoys learning about design systems and is trying to create a resource for other people to also learn from. Tons of knowledge already exists, but that doesn't stop people from trying to create or share new approaches to it anyway.
This reminds me of open-ui [1]. The goal of that project is also to tackle fragmentation and allow interoperability between component frameworks and design systems. How does UI Playbook compare to it? Do you think collaboration between the two projects would make sense?
Accessibility is a whole beast in itself. It'd be cool to give quick suggestions on how to make the components accessible. The W3 docs are good if you want to dive deep and understand the nuances, but a quick handy reference of good accessibility patterns for common components would go a long way. For example on buttons you could add something similar to this: https://a11y-101.com/development/aria-disabled.
Not as i expected but, great work, continue, maybe in the future it doesn't just a display of only 5 different things that i already know, and one of them isn't clickable.
This is a website detailing various UI components whereas storybook is a development tool where you can manipulate and view components you are building locally (although some people end up hosting a static version of their storybook somewhere).
Was wondering why OP only seems to recommend reach-io as examples, turns out they are a contributor. It’s all open source so like, you’re not doing anything malicious for profit here, but it would come across as disingenuous if you didn’t mention being a contributor to the most prominently linked example system if this is supposed to be system agnostic documentation
No it is not, a disclaimer is very low effort. Here is an example disclaimer: "Just a heads up, I am a Reach-UI contributor!"
That is in no way a large burden, still gets the message out about both UI Playbook and Reach-UI, and is just the more respectable thing to do here. I really don't think OP did anything WRONG, there is clearly no malice here, it's just an observation I had to better communicate in the future for the people like me who care about these details, I know I am not alone here.
