Show HN: UI Playbook – A documented collection of UI components | Hacker News Reader

Show HN: UI Playbook – A documented collection of UI components

uiplaybook.dev

145 pointsraunofreiberg33 comments

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.

Fair point

Hey!

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.

List of corporate sponsored design systems: https://designsystemsrepo.com/design-systems/

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.

It's not a design system. It's documentation/best practices around common UI components that you'd find in most design systems.

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?

[1] https://open-ui.org

I would recommend a couple of things:

Sidebar with links to headers similar to other documentation sites.

And if you are going to provide insights on accessibility, which is great, make sure your site is also accessible.

Care to elaborate which parts weren’t accessible for ya? Thanks.

Install an accessibility tool such as the Wave browser extension and you can see some of the issues... eg. missing form label and contrast.

Very cool resource! Thanks for creating it.

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.

Overall, looks awesome!

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.

> yes, there's a search for 5 components

I mean, the 5th one isn't even available yet, just a teaser. :)

I don't get it, why isn't the "select" box opening, i.e. showing a dropdown?

The select at the top isn't actually a select input, if you scroll down to examples it has an actual select box.

You're right. Hmmm, I don't think it's very good UI design to show a UI element that turns out to be just an image or a button.

nice, will bookmark it for later use when there will be more content :) thanks for the effort!

What are the main differences between this and storybook?

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).

What UI components did you use to build the site.

Nice! This is awesome!

Why no spinbox?

Had to look it up. I think these are more-commonly called "Number Input Box" ?

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

The documentation itself is system agnostic. You don’t need to use Reach UI for the docs to make sense.

I recommend Reach UI because in my experience it has worked out great. Feel free to extend the examples with additional libraries! :-)

> but it would come across as disingenuous if you didn’t mention being a contributor to the most prominently linked example

No it wouldn’t. That’s a lot of disclaimer burden to put on someone.

> That’s a lot of disclaimer burden

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.

Reply on news.ycombinator.com