Investing in Blueprint

[mischacolley]

Hey @aimementoring/engineering I want us to collectively work on a roadmap for really fleshing out how we are going to invest in blueprint from now on so that we know we are making solid decisions. @kbardi if you can keep leading this project that would be 👍🏼

Some initial items I have:

Maintainability & Future Proofing

• What do we need to consider here?
• Are there any issues with the NPM hosting approach?
• What happens if we aren't using CRA or webpack in a project etc? // I'ms specifically thinking about this in relation to the Website Architecture and how that could potentially change ...

How can we significantly improve the developer experience and thus our speed?

• How should we allocate time on this? Below are some issues to get us started.
• https://github.com/aimementoring/blueprint/issues/22 will help with reviews
• https://github.com/aimementoring/blueprint/issues/28
• @lulen11 anything particular slow you down?

Design to Code Workflow

• @charliemckenzie what's your process need to look like here?
• @lulen11 @davidpaley thoughts?

Performance Considerations

• How large is the bundle we are sending?
• What if we aren't using one themes on one of our sites? Is all the CSS still there? etc etc...

Accessibility Considerations

• If we invest in this now then we reap the benefits through all our projects. i.e. starting with something like https://github.com/evcohen/eslint-plugin-jsx-a11y

What should go in Blueprint

• This should be very prominent in the docs ... How do we vote on what components make it in? A proposal label on issues?

What am I missing?

[lulen11]

• How can we work on removing unnecessary styles on our individual projects once we start building out each of the blueprint elements?

Design to code:

• I think we need to flesh out our Figma version of this and then when @charliemckenzie or one of us are happy with the instances we've got of an element, use Figma comments to notify the dev team that we can move forward with it in Blueprint.
• Then I think we need to have instances to test it in - Check that positioning etc isn't influencing the element's style. That it can be used across multiple contexts, and across multiple browsers and devices.

Side note, I think we need to have dedicated time each fortnight when a small team (or singular people) work on this. I can see it getting pushed back and back because it's a "nice-to-have" (we know it's more than nice) but if we commit to "Blueprint Fridays" or something, I can see it progressing well.

[kbardi]

Hi team,

I agree with Lara, I think we can make better things basing on Figma first.

• About positioning, it would be great, at least for me, if we have some docs saying which styles we should use for positioning and what no, and write like a styleguide...in the same way we talked about pixels, em, rem. It could help us (dev team) to create the component with right styles.
• Writing a list of component we need or we use in many places can help to organise our work on Blueprint, knowing pending components, repeated components across multiple platforms, ect...
• Test (If any dev has some time to spend writing unit test, it will make blueprint more stable and robust). I created some tests, but working as a team with that is better, and you can consider border cases to test I didn't consider...this is an IMPORTANT ONE

Answering some questions about Maintainability:

1. We have to consider that unit test will help in the way if I change something, I want to be sure I'm not breaking any other thing.
2. We have to consider library versions that we use...if we use always the latest version is good in some ways because we have latest features, but compatibility between blueprint and projects could generate issues, so it's important to test always blueprint with the projects we use it.
3. Simplify more the deploy and publish process could speed up and reduce errors.
4. About npm hosting approach, I think we have no issues...The only thing is right now blueprint is public...The good thing is we have our first Open source project, which is nice, but also we have to be careful about adding sensible information and environment variables in repo.

[charliemckenzie]

In terms of design to code, that a tricky one. I agree that we need to have some common defined styles. @mischacolley & @lulen11 you css wizards will be great for this maybe? I agree with @lulen11 @kbardi starting in Figma will be the go, and marking them with comments when they're ready is great too. We could also put our notes in these comments, so it really ends up the way it was intended :) My thoughts initially are to work iteratively through it, as they pop up in whatever i'm designing. And maybe I should allocate a bit of time every day to giving some love to the instances/components? just so I can hopefully be 2 steps ahead, and we don't fall behind dev wise. Then if we've got a hole bunch of these components ready, pulling together the new website will hopeeeefully be a lot smoother?

Thoughts?

[lulen11]

Remember when we first started thinking about this yonks ago and I started going through the website and doing a screenshot audit? I think we could go back to doing that and that would with what @kbardi noted:

Writing a list of component we need or we use in many places can help to organise our work on Blueprint, knowing pending components, repeated components across multiple platforms, ect...

This would help us gather and refine what components are needed.

And, similarly:

About positioning, it would be great, at least for me, if we have some docs saying which styles we should use for positioning and what no, and write like a styleguide...in the same way we talked about pixels, em, rem. It could help us (dev team) to create the component with right styles.

We could create badges in Figma to explain positioning and what is for a medium breakpoint etc. ? We could treat it like a scrapbook to prep for blueprint.

[rin]

Hey! I'm a little late to the discussion so I feel everything has already been said …

Designing in Figma, then notifying devs -> good idea! How about the design team then creates a github issue for the element and adds a comment in figma with the link?

I second @lulen’s idea of “Blueprint Fridays” … or maybe more general “Housekeeping/Things that get pushed back/Refactoring Fridays”.

I also love @kbardi’s idea about having a styleguide how to write “good” CSS, and I want to learn more about it! We could first do a call/recording where some basics are explained, and then put it into writing and into our docs repo … or into blueprint? 🤔 From the top of my head I can think of a few questions I have, that I could probably also google but that I would love to have explained by Lara or Misch or David rather than some random person on stack overflow :) .

[mischacolley]

Designing in Figma, then notifying devs -> good idea! How about the design team then creates a github issue for the element and adds a comment in figma with the link?

@rin ^ Yep something I want to discuss with @charliemckenzie today as he's been doing some thinking on process :)

Re "Blueprint Fridays" + other names. I'm 100% onboard with this idea and looking to schedule some reminders!

Re CSS Guide I'm also on this