Re: [community-group] [RFC] Format specification (#1)

Hi guys, I'm CTO of GeneXus a Low Code development platform, GeneXus probably will be a user of any outcome of this group. 
I've have been following the conversation, we are really interested on the final result of this group.
We have being working on several of the topics around Design Tokens because we are allowing modeling Design Tokens inside our platform, we couldn't wait to have a final specification so we started as many our own. 
Obviously we are open to try to find a unique way to specify design tokens for design not only for web but for mobile native apps too.

The definition of our Design Token language is still a working process and you can take a look on it and leave us your comments on the language we are defining. 

We decided on several things we are discussing here:

- We created a new format for Design Tokens

ie:

tokens MyDesignSystemTokens
{
  **#colors**
  {
    Primary: rgb(108, 154, 235);  
    Secondary: #ab2;
    Background: rgba(200,200,150,0.9);
  }
  **#spacing**
  {
    Small: 12px;   
    Medium: 22px;        
    Large: 45px;
  } 
  **#fonts**
  {
    Primary: arial;   
    Secondary: georgia;    
    Third: roboto;  
  }
}

- The concepts of the language are: TokenSets, Token Type, Token Name, Token Value
- Tokens can have associated metadata
- There are parameters for TokenSets and conditional tokens based on those parameters.

The Tokens are the options of my Design System, but those options can be grouped on Token Sets, there are cases where just a small set of token options need to be changed, for example a token set for a Dark or a token set for Light.

Imagine your design system is called Unanimo, Unanimo has two defined token sets, Dark and Light, so instead of defining twice. We define our token set in the following way:

tokens Unanimo(option : enum(dark, light))
{
   @ $option is dark
   {
     #colors
     {
        text = white;
        back = black;
     }
   }
   @ $option is light
   {
     #colors
     {
        text = black;
        back = white;
     }
   }
   /// The rest of the tokens here

}

Then after that the designer can use the Token Set options in this way: Unanimo(dark) or Unanimo(light) in any place where the styles are defined for the Design System.

The working specification is here [GeneXus Design Tokens Specification](https://github.com/genexuslabs/designsystemtokens)

You can try the language real time on [GeneXus Design Tokens Editor](https://gx-design-systems-editor.netlify.com/)
Basically is a side by side editor (textual - visual) for Design Tokens. It's an alpha version but it works ;) 
Just try to paste some of the samples given in the specification page to see the idea.

We didn't decide yet if we are going to use functions as values for design tokens. At first we are going to keep it simple and do not allow to use functions and function composition as values for tokens, but i'm still have doubts on the topic of token dependencies and token values. Because of that you will find a 404 page if you follow the Token Type link in our specification ;)

For us things like metadata will be very important for tooling, metadata that for sure we will use are:

- Tokens Converters (How to convert the value of a token to other types, units, etc)
- Tokens Type Editors  (How to edit this token type for a given tool)
- Tokens Descriptions (How this token will be presented on UI widgets like can be a property inspector)
- Tokens Valid Resolvers (In some contexts the token value should have some kind of extra validation more than just the token type validation)



-- 
GitHub Notification of comment by gmilano
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/1#issuecomment-593749952 using your GitHub account

Received on Tuesday, 3 March 2020 03:34:30 UTC