Component Library - 11th Oct Meeting Notes

Archive UX and UXR
1

Component Library - Meeting Notes

Date: 11th October 2018 @ 5pm CET
Attendees: @andmironov, @cryptowanderer, @barry, @denis , @Graeme , @patrick , @hester , @Euge , @Ned, @naghdy

TL;DR: Next Steps

Short Term

Long-term

  • Build a design system that unifies offline and in-app brand identity [@Ned]
  • Hire a UX Engineer to build out and maintain the component library (example JD). [@naghdy]
    • Potentially customize visual styling and behavior of the long-term design system into a native Status UI. This can be decided and discussed at a later date.

Overview

This meeting tried to tackle 4 topics:

  1. What are the existing engineering needs of core and community contributors from a component library?
  2. What are the existing needs of DApp and/or Extensions developers from a component library?
  3. What is the component ltibrary Andrei and co. building today trying to solve?
  4. What is the Brand Identisy Design Platform that Ned is building trying to solve?

Developers

Contributor building Status Core app

  • Developers end up having to do design using flat images, usually for the first time
  • Using component libraries is a much better way to operate
  • Bringing people in from the community to contribute, using our style convention fosters that
  • Examples of good component libraries:
  • Storybook is a framework to house this
  • Creates a unified conversation between product, design, engineering.

Design

General consensus from Design.

  • Core app: current components documented
  • DApps are webbased, therefore will have different components. No components for this yet. Visual style is applied in designs.
  • Extensions

Specified components for the Core app can be implemented in Storybook as React components

The following Core app components can be implemented in Storybook: https://www.figma.com/file/cb4p8AxLtTF3q1L6JYDnKN15/Index?node-id=0%3A1

–UNSTRUCTURED NOTES–

Blockers

  • Time
    • There’s no way of knowing what type of components would need to be in the component library.
    • (earlier blocker) Components need to be designed first.
      • This situation will occur with every new component that is introduced.

Solution

  • Front end dev in design team
  • Profile needs to be specified offline
  • Could be Andrei or Maciej as well
  • Bounty on component development in Storybook
    • Barry can do the code review on bounties
  • Collaboration with community (Beltran, Aqeel, Alejandro) / Potentially more difficult to collaborate at this point in time.

Currently there is no library of web3 components.

Detailed notes

  • Central place where we have the base UI elements in a design as usable components.
    • There might be confusion around what a component means.
    • Everything is a component, you combine them to build something bigger. Button is a component.
  • Helps a unified conversation between stakeholders. Designer give name of component and developer doesn’t have to rebuild the component.
  • Creates clarity on what materials to work with and what constraints are.

Consequence of not having component library
- Copying from Figma with fixed dimensions
- Developers have to recreate components and taking on a designer role.
- More difficult to bring in people from the community to contribute. Having a library using our style conventions would foster that and would make us more productive.

What is the “Brand System” (that also contains components) that Ned is working on? What is it trying to solve?

  • Longterm would be a nice scenario.
  • Goal is to empower people with free tools is different from we want a specific set of products.
  • Bigger system could emcompass these free tools across products.
  • A unified brand accross touchpoints; meaning that the product components are related to print, web and other materials.

Challenges short term

  • Code division in web2 is different from web3;
  • Limited resources.
  • We don’t have the optimal patterns and flows for ourselves.
2 Likes
2

Would be useful to get Clojure input, maybe @julien and @andrey have thoughts? We want to make sure what we create can ideally be used both for CLJS, vanilla minimal framework agnostic lightweight, and React.

3

Do you mean for status mobile and desktop? We would need an implementation of those in ReactNative.
Now the most important is to have components specified and mockups based on those components.

4

if we’ll use CSS flex-box layout for web components, it should be better compatible with react native components for status, or we can consider using https://github.com/necolas/react-native-web library, in that case we’ll have same components for web and status.

RNW storybook https://necolas.github.io/react-native-web/storybook/

Edit: But I’m not sure how it’s fit vanilla minimal framework agnostic lightweight. tbh it’s not a big problem to implement components in fiddle, so maybe we can choose the best way for web components , describe them in story book, and just port them in fiddle for status, maybe i’ll find a way how to do it automatically

5

I think trying react-native-web is a good idea, I’m more uncertain about how the current components are written in clojurescript which means modifying the build process of storybook or writing react-native components using vanilla JS. I’m not sure what kind of challenge the second option presents to clojure devs?

6

Hey people, could you take a look at this Status.app :slight_smile: