The same tech (HTML/CSS/JavaScript) is used for different end results. Most applications are not purely one category. A UI library is great for all kinds of web products:
website / blog / documentation | admin / profile / cms / forms | visualization / charts / tables |
display unstructured content | edit content, view status | display structured data / stats |
* typography
* styled components
* article width / center on page
* show more
* infinite scroll
* scroll effects
* photo / video / audio
* code (for documentation)
* preview (for documentation)
* carousel / slideshow
* footer / lists
* pagination
* link | * notifications / messages
* add/edit tags
* navigation menus
* tabs
* confirm password input
* toast
* sidebar nav (floating)
* upload (or drag and drop files)
* tooltip/popover controls | * all kinds of charts and graphs
* network diagrams, mind maps
* SVG/D3 custom development
* canvas element |
maybe call it: content | maybe call it: edit | maybe call it: visualization |
website/blog + admin/profile/cms/forms | admin/profile/cms + visualization/charts/tables |
used for both websites and admin/internal tools | used by all kinds of internal and industry tools |
* input (text, number, password)
* textarea, WYSIWYG editors, content-editable
* toggle/checkmark/radio controls
* hide/show content, accordion, menu, dropdown
* date/time/calendar select
* loading spinner
* card
* svg
* tag
* form validation
* modal (or lightbox for website) | * sliders/ranges
* interactive/sortable tables
* markdown / json
this really doesnt deserve its own category, should just be bundled with another group |
maybe call it: form, or focus, or nav? | maybe call it: data, or maybe code, idk |
website/blog + visualization/charts/tables |
used by news and trends sites, and widgets embedded into blog articles |
* map
* avatar
* layout / grid / responsive
* dropdown menu |
maybe call it: idk |
So how to organize a component library? I don’t want to have 5 different sections for all these, especially because these categories have a lot of overlap, are difficult to remember, and may not make any sense for some use cases.
Admin dashboards, data visualization dashboards, interactive tables viewed in a web browser - they are all still websites, and have the same needs as a marketing/blog website. Even though time to first render and time to interactivity is not as important (because you’re less likely to lose the user’s attention), it is still important for good UX, so the user does not get annoyed with your product. They still require layouts (sidebar, main content, header, footer, etc) like websites. Etc.
Maybe better to think of it as a pyramid. Like Maslow’s hierarchy of needs but for a website.
visualization / charts / tables (top of the pyramid) |
display structured data / stats |
* all kinds of charts and graphs
* network diagrams, mind maps
* SVG/D3 custom development
* canvas element |
admin / profile / cms / forms (middle) |
edit content, view status |
* notifications / messages
* add/edit tags
* navigation menus
* tabs
* confirm password input
* toast
* sidebar nav (floating)
* upload (or drag and drop files)
* tooltip/popover controls
* sliders/ranges
* interactive/sortable tables
* markdown / json |
website / blog / documentation (base) |
anything that could possibly be used in a public-facing website - but could be used by dashboards too |
* typography
* styled components
* article width / center on page
* show more
* infinite scroll
* scroll effects
* photo / video / audio
* code (for documentation)
* preview (for documentation)
* carousel / slideshow
* footer / lists
* pagination
* input (text, number, password)
* textarea, WYSIWYG editors, content-editable
* toggle/checkmark/radio controls
* hide/show content, accordion, menu, dropdown
* date/time/calendar select
* loading spinner
* card
* svg
* tag
* form validation
* modal (or lightbox for website)
* map
* avatar
* layout / grid / responsive
* dropdown menu |
What’s the point of this exercise?
I’m building a component library (for myself, but also for future employers and clients). Why? Because I’m tired of struggling with messy architecture. Even if I fully embrace an off-the-shelf open-source library, then I’d still have to restyle and customize some components. The best way to do that is to start your own component library as an abstraction. That’s why everyone is building their own component library these days.
I don’t know how to group and name each category of components. I don’t want to have to refactor and rename a lot of files and references in a codebase later. This codebase I’m working on - I hope it can be long-lasting or even timeless.
Any suggestions?