EddieHub Community Design System

[MatteuSan]

[Transferred from #3845]
[Updated version]

I've been thinking about this concept for a while. I saw the EddieHub website and (no offense) I thought it looked a tad bit inconsistent in some places (buttons have different styles, theming is a bit all over the place, etc.), and that's where the spark began.

Goals

The goals of this design system are:

• To represent the EddieHub community as a whole. Create an identity, a motif if you will, throughout every EddieHub project (current, and future).
• To minimize time doing the project. Make a set of design principles and patterns that govern the EddieHub community. This way developers don't have to waste time reinventing principles and patterns for each project.

Conceptualization

I began thinking of how the EddieHub Community works, because if we were to build a design system, we have to know how things work internally, how the people will use the code. This was an immediate roadblock for the conceptualization phase. EddieHub projects are created with the community in mind, and I felt that putting a design system in the middle of every project making process makes it sort of limited in a way. I felt the idea makes less room for the individuality of each project, to which is one of the beauties of the community. I think this would be a fun and challenging project to take on despite the roadblocks.

Implementation

Like every developer, we're all excited to get our hands dirty into the nitty-gritties of this project. However, I would like to point out that we're making this with the EddieHub community in mind.

1. Have a 1-3 month period where it's just full of research and surveys. Asking the community their preferences when it comes to using styling frameworks, how they organize styles, their preferred technologies, their preferred methods for styling overall.

   • In parallel to this process, we'll also assess all of the projects (and possible future projects) in what type of environments will they be developed in. Its front end stack to be specific.

2. Assess all patterns, practices, principles, and components in projects to determine the design system content. Then design and put it all in figma.

3. Create the implementation in its code form. Of course, we will collect, sort, assess, and apply the results in the research and survey to the code implementation.

   • In parallel to this step, a figma UI kit will also be created for all the designers out there.
   • The implementation will always follow this workflow cycle:
     1. Create a markdown spec of the public API that the developers will interact with. This way we can minimize code refactoring, and have good documentation. Of course every spec will be code reviewed to see if it passes the requirements. (The requirements are to be determined based on the research and survey).
     2. Code the thing from the spec. And of course this will (again) be reviewed.
     3. If we want to change something, go back to step one.

4. Maintain the codebase. Design systems are living, breathing projects. It grows as the organization grows.

Conclusion

Despite the roadblocks, I think it's going to be a fun challenge. To create a design system despite the constraints given.

Thoughts? Any feedback (may it be positive or negative, as long as it's beneficial to the proposal and constructive) is greatly greatly greatly appreciated. :>

[MatteuSan]

Bumping this

[eddiejaoude]

Thanks Matteu! It would be good to have these types of things more formalised, however I have a concern is the timescale, not because we are in a hurry, but because these type of things get excitment at the beginning then everyone get's distrated with something else (me included)

[MatteuSan]

@eddiejaoude Yeah, the hype needs to be considered. But for the most part I think it's normal for a design system to go like that. I think it'll be fine if it's only going to start with a small group of people working on it.

[Cahllagerfeld]

I think it would already be a huge improvement if we provide a CSS-Sheet with an Eddiehub color scheme for light and dark mode in the first step. People could include it via a script-tag, copy the variables to their project or we publish it as an npm package. By doing this we wouldn't need to make the whole roundtrip with Figma, the official website, etc... (which we could still do in the future) but also bring consistency to our github-repos. Let me know what you think about this @eddiejaoude @MatteuSan, or if I can support with it 👍

[MatteuSan]

@Cahllagerfeld We can consider that as a possible implementation, however we do need to ask everyone first their styling preferences (ex: do they prefer utility only over a semantic approach to styling).

[Lucky-victory]

I agree with this, when I visited Eddiehub's website, there were a series of inconsistencies that needed to be fixed.

[grayoj]

Exactly. 👌

[EmmaDawsonDev]

Thing is the Eddiehub website is built with a low code site and so the question is how flexible it is to fix the inconsistencies. And is the thought that every Eddiehub repo should then follow the same system? Just wondering as different repos are currently using different css solutions, some use component libraries and others use tailwind

[eddiejaoude]

Great questions! My thoughts

• the website I think is too difficult to customise, but we can try
• the repos should be made more consistent in terms of naming/actions etc, but with regards to technology maybe having some differences is a good thing so people can get involved in the tech they prefer, what do you think?

[MatteuSan]

And is the thought that every Eddiehub repo should then follow the same system?
@emmalearnscode

Yes. However, since this is a very different community compared to the previous one I've worked on before, it's going to be a challenge to implement a very open/non-restrictive design system while still maintaining consistency. I do have a few solutions in mind from previous design systems I've worked on, one of which is Design Tokens. Here's an example of a design system that runs on design tokens, it's the latest design system I've worked on so far (https://hashi-docs.netlify.app/docs/develop/concepts#token-driven-architecture).

[MatteuSan]

• the repos should be made more consistent in terms of naming/actions etc, but with regards to technology maybe having some differences is a good thing so people can get involved in the tech they prefer, what do you think?
  @eddiejaoude

Yes, I do agree on this. Which is why research and writing specifications is first, this way the design system can adapt to any tech stack developers wish to use.

Naming conventions are part of the design system since this creates a singular language developers speak. For example, it would be a bit confusing of one project calls a component a "menu bar" while the other calls it a "utility bar". Having common terminologies and names for elements, actions, philosophies, concepts, etc. is important to create less divide amongst projects.

[mkubdev]

I haven't been here long 😋 But i feel like EddieHub is not an identity but a philosophy. Will adopting a design system optimize or reduce creativity?

[MatteuSan]

I do think philosophy is part of an identity therefore I always include that whenever I work on a design system.

To answer the second question, design systems can be as flexible or as constrained as you want to, it depends on the implementation for the most part. Creativity wouldn't really be a problem if the specifications allows you to deviate from the system in certain cases. For example, in Hashi we've used a token driven architecture, and a primitive-only approach. This way, each projects can solve their own design problems while still enforcing the design language.

[MatteuSan]

Hello, any updates on this?

[eddiejaoude]

There are still challenges on how to standardise this, for example the website is created in a no-code platform where we have limited control, all other projects are open source but use different libraries and frameworks. We have started using Storybook in the Finder and LinkFree project.

How do you think we can solve these challenges?

[MatteuSan]

@eddiejaoude with regards to projects using different libraries and frameworks, there are two ways we can approach this.

First being create an implementation of the design system for each unique library/framework we use. This option is very tedious, so I don't really recommend doing it unless need be. The second option is picking a technology we already use, and already has the capability of being framework agnostic (e.g. Plain CSS, SCSS, Tailwind). Yet again, as previously mentioned, we need a couple of months asking the community if they're okay with the technology we're gonna pick to implement the design system on.

As for the low-code website, since you said there's limited control, I don't really think there's nothing we can do much about it unless it gets a major renovation (like taking it off of the no-code platform and the community building it again from the ground up).