Game Plan for Redesign of MetaBrainz

README.md

We are on our way to have a castle of pixel perfect pretty mockups. Will that castle be but an illusion? Sorry, for being so dramatic. What I am trying to say is, we need a plan on how to build it. And here are just some of my thoughts about it 😄

Our present game plan and all that is wrong with it

• Have the mockups ready
• Then someone, with some knowledge of how code works, will slice it up into tickets.
• Design-person coordinates on making sure every ticket owner has what he/she/zhe needs. Hey, where do I get this font? Is this the latest icon set?
• Design-person crosschecks when it’s done. It goes up and live.
• Someone finds we used a different button somewhere. We have a ticket. Which then needs to be taken up by someone. And before we know it, we have huge piles of UX-debt. I feel this is a very probably scenario, seeing the huge scale of projects we have.

The very obvious solution

To maintain uniformity, static HTML/CSS document with all the components, buttons, colors, icons in it. Even code snippets with it. Developers can just copy paste from it. Something like this.

Problems with it

• As soon as it’s completed, it will be outdated. Something would have had changed by then.
• Say, we decide to make the all buttons round on MetaBrainz. We change it in our style guide. Changes don’t reflect everywhere. Some developers don’t even know, something needs to be changed.
• It will be a pain to maintain it.

So what do we do about it? We want all our projects, which have been built as independent silos over time, 
to now have same cohesive user experience. They need to belong to one family.

Here, I think we need a list of goals we wish to accomplish from this “style guide” 

1. Shared, single source of truth. If it’s there, it’s the one.
2. Organised. I know exactly where I can find that one dropdown.
3. In-sync. Changes should be updated real-time.
4. Self-contained. Changes to it, shouldn’t break anything else.

On doing some (actually lot of) research, I figured what we need is a component-driven design system. Okay, what is that now. Let me explain it to you.

Component-Driven

It is a lot like the principles we are following in React. So designers still make mockups keeping the overall user flow in mind. They then break it down into elements and components.

We have elements. The Heading, links, grid icon, etc will all be treated as an element here.

And together, they make a “component”

Before

Designer: This is the new feature. We have several same looking headers.
Developer: Hmm.

After

Designer: For this new feature, let’s plug in the card_header component here.
Developer: Okay!

What will happen

• All components are independent and reusable across various contexts. They speak the same design language.
• The designers can use components as the primary means of sharing the UI with application developers, instead of wireframes, mockups, style guides, or prototypes. We have a common language.
• We avoid the handoff process from designer to developer, it becomes continuous. 
• A lot less dependency on designers.
• It will encourage contributors to contribute more freely to the library.

Design System

Very simply put, design system is a story about how we design and build products. This is how we use colors, this is how we use icons, this is how dropdowns are supposed to be, this is how buttons are to be. So if a new developer or designer comes in, it acts as a guide for them.

So now I hope, component-driven design system makes sense to you. Next thing will be how to implement it.

React Component Library

After exploring various options, the best suited way for our context is to have a GitHub repo with all the React components, colors, iconography, typography, guidelines, etc. We can either

• publish it as an npm package using semantic versioning
• reference git repos in package.json without publishing to npm (pushing versions as tags)

I suggest it to be something like this.

├── README.md
├── Design Guidelines
│   ├── design_guidelines.md
├── Assets 
│   ├── Colors
│   │   ├── colors.less
│   │   ├── colorspalette.ase
│   │   ├── color_guideline.md
│   │   ├── colors.less
│   ├── Typography
│   │   ├── font_guideline.md
│   │   ├── font.ttf
│   ├── Grids
│   │   ├── grid_guideline.md
├── Components
│   ├── Images
│   │   ├── entity
│   │   ├── favicons
│   │   ├── flags
│   │   ├── icons
│   │   ├── leaflet
│   │   ├── licenses
│   │   ├── logos
│   ├── Layout
│   │   ├── UI Elements
│   │   │  ├── buttons
│   │   │  ├── links
│   │   │   ├── ..
│   │   ├── UI Components
│   │   │  ├── Cards
│   │   │  ├── Modals
│   │   │  ├── ..
│   │   ├── UI Patterns
│   │   │  ├── Forms
│   │   │  ├── Authentication
│   │   │   ├── ..
│   │   ├── Page Templates
│   │   │  ├── Home
│   │   │  ├── Entity_page
│   │   │  ├── ..
├── package.json
└── .gitignore

For building the React components, we can use a third-party UI library, probably Bootstrap. The design guidelines will be a set of guidelines which define how we design and build our component library.

Testing

I have not researched this part well, but we will probably use Selenium tests for impl. atoms/components

After initial setup phase, we should hope to release this for contributions and downloads. Guidelines will come in handy here to monitor the contributions we get. Once we have this for MusicBrainz, other Brainz project can possibly fork and use similar design systems for their development.

Hope this made sense. Happy Feedbacking 😄

components.png

elements.png

static.png