Skip to content
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

Improve global look and feel of the pattern library #106

Closed
ThePeach opened this issue May 1, 2018 · 4 comments
Closed

Improve global look and feel of the pattern library #106

ThePeach opened this issue May 1, 2018 · 4 comments
Assignees
Labels
infrastructure CATEGORY: Infrastructure related - e.g. updates to build process, tests, tooling, etc. 🌟 enhancement TYPE: Indicates new feature requests WIP STATUS: Work in Progress - Do Not Merge. Useful for long-running PRs

Comments

@ThePeach
Copy link
Contributor

ThePeach commented May 1, 2018

As an effort to make this pattern library easy to browse and consume, I'm opening this ticket as I think we can proceed with a series of small improvements that can largely affect the way we use, consume, and improve this tool.

I'm trying to keep the conversation in here so we are aware of the decisions and what is needed to be done.

Here's a random list of things that I'd love to address:

  1. Particles section should be revisited with a more precise intent and it should be documented, we are effectively expanding Atomic Design to include something that is not part of the definition of the design methodology and should be noted down. This seems to fall very much into the Design System area and the "let's put it here until we have a better place".
    1. with this in mind perhaps it's just a question of making this a more textual explanatory area and have a small introduction. Nothing wrong in having a simple md file that deals with it. (I have no idea how to achieve this, will need investigation)
    2. we are currently missing a show how responsive typography works via gravy/typi: we ought to showcase how the various sizes are working across various breakpoints and how they relate to each other size-wise. At the moment it is a bit tricky to understand and use them correctly. This is a very important bit IMO.
    3. widths/heights, variables, vertical rhythms... all part of the above problem, probably it's just a question of finding a way to display this info in a concise and simple way.
  2. Atoms:
    1. classless atoms: the list is annoyingly long and possibly useless for various reasons. Perhaps grouping all atoms in a more cohesive way could be the best way to approach this, an example could be how many other companies are doing this in pattern libraries by writing a excerpt from a book. Clearly the intention is the important bit, this type of markup is stuff that we would potentially use in parsed markdown data, so I think it's fair to be represented as such. As far as I can see, majority of these atoms might not be even be used as patterns via template inclusion as they require custom variables to be passed into them.
    2. atoms with classes: although, as in the previous case, all these classes might not be used as patterns via template inclusion, their aggregation might be a bit more tricky. Specifically when it comes to buttons or special headings or lists.
  3. Templates: We need to be more careful on the way templates are shown and their actual intention. We have an homepage that doesn't show anything between the header and the footer... not ideal.
  4. Pages: this is valid for templates as well: these should be removed from the global listing, so I'd rather avoid having the "generic page" example at all (that is, avoid grouping via subfolders).

I'm completely happy to split this ticket in sub tickets as soon as we come to the conclusion that any of what we will discuss is worth investing time into.

@ThePeach ThePeach added the 🌟 enhancement TYPE: Indicates new feature requests label May 1, 2018
@james-nash
Copy link

Thanks for opening this @ThePeach, this is definitely a subject that warrants further discussion and, I'm sure, will spawn quite a few tasks.

Here are my initial comments, thoughts and ideas...

Particles

Agreed that these have been shoehorned into PL as there was nowhere else to showcase them. We should rectify that. Some options we might consider are:

  • Use a commercial product like InVision DSM, ZeroHeight, Frontify, etc. to store and document these design tokens and docs
  • Start building a "storefront" style guide website (perhaps drawing inspiration from Brad Frost's "Style Guide Guide" boilerplate: https://bradfrost.github.io/style-guide-guide/)
    • FWIW, I believe we should eventually have something like this anyway - and I can see that co-existing happily with an online pattern library like our current Pattern Lab one.
  • Expand PL's UI to better accommodate this stuff, as you suggest
    • I've never really looked into PL UI customisation, so no idea how easy or hard this might be. I believe PL3 should be making this sort of thing easier to do though...
  • Switch from PL to Fractal which already has a dedicated docs section for exactly this kind of stuff

Whatever we end up doing, my only hard requirements are:

  • Single source of truth: Even though design tokens and docs may be surfaced in multiple places, I should only ever need to make changes in one place to update them.
  • Automate as much as possible: When I tweak my single source of truth, I want it to roll out to wherever it needs to with zero effort :-)

Atoms

I think there's a lot of value in PL's lineage feature to help Gravity consumers and maintainers better understand which UI components other components are composed of. Likewise, to determine what will be affected by changing, say, an atom.

I know due to limitations in Mustache and PL it's not always practical to {{> xxx}} include things all the way down to atoms, so you can get 100% lineage coverage. However, I'd like us to find ways of exposing those lineage relationships as much as we can while still being pragmatic.

As for the classification of what, exactly, should be an atom and what not - I'm sure we haven't got that quite right yet. So, definitely support reviewing and revising that stuff. Maybe we can do another UI inventory exercise?

Templates & Pages

Now that the Buildit website is mature, I think we can simplify what we have in PL. It's useful to include some templates and pages as examples of what you can build with Gravity, but they do not need to maintain parity with the live site.

On a related note, I'd like us to revisit the whole section organism. I know it created a lot of confusion with some of our developers while making the website. I think we can afford to dumb it down for the sake of making the template examples easier to understand.

@ThePeach ThePeach added the infrastructure CATEGORY: Infrastructure related - e.g. updates to build process, tests, tooling, etc. label May 9, 2018
@james-nash
Copy link

The issues raised here have been or are being addressed by a various other issues and PRs.

...and the remainder of adding some docs into the pattern library and making it appear more inviting are sorted by PR #350, which will close this issue.

@james-nash james-nash self-assigned this Sep 24, 2019
@james-nash james-nash added the WIP STATUS: Work in Progress - Do Not Merge. Useful for long-running PRs label Sep 24, 2019
@buildit-dev
Copy link

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@james-nash
Copy link

Closing this issue, since it's just repeating what's now being (or, in some cases, has been) addressed by other issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
infrastructure CATEGORY: Infrastructure related - e.g. updates to build process, tests, tooling, etc. 🌟 enhancement TYPE: Indicates new feature requests WIP STATUS: Work in Progress - Do Not Merge. Useful for long-running PRs
Projects
None yet
Development

No branches or pull requests

3 participants