Open AlexJupiter opened 6 years ago
@AlexJupiter @marikio I have created a list for the Design Language so please fell free anything that you think is missing here
I think we can look at Atlassian guide https://atlassian.design/ and take it as an inspiration and see which design language guidelines we might be missing ?
@agazima nice start, however I would remove the following from your list, as I see these living in the component section:
To try and reduce the confusion of our five categories, let me try and define each category now. However, please keep in mind that the boundary between each of these categories is blurry, and we may decide that something might change categories at a later date once we have more information.
Principles These are the general instructions for designing. These should be a general introduction to our design approach. Examples of what to include here, would be design principles and brand guidelines.
Language These are more sophisticated, specific instructions. These are rules that all the designs need to apply by. Examples of what to include here, would be grids, spacing, colours.
Components These are the smallest level of user interaction, that are the manifestations of both the principles and languages. Example include, buttons, cards, voting sliders, tables.
Groups These are a collection of components, that are grouped together for a specific interaction. For example, the header. These are a bit more difficult to define, so definitely checkout the examples I put in Figma here.
Templates These are a single page. This is what all the principles, language, components, and groups create. These are the designs that will be given to the engineers to understand what they are creating, as they give the clearest insight into the designer vision for the product.
@AlexJupiter i totally get it but what about writing guidelines for the components as you can see in the image below, do you think it's necessary?
@agazima we have issue #5 currently in the "To do" column, is this what you mean?
@AlexJupiter you are right. this is what i meant
_@AlexJupiter What naming are we going to use for typography; h1,h2,h3 or small, medium, large? Should the font weight be included in the typography styles together with the size of the font? How detailed you want to go with describing one font style, example
Could i get help with what the grid that we currently have for dapp and design language should say about this grid?_
Typography is used to create clear hierarchies, useful organizations, and purposeful alignments that guide users through the product and experience. It is the core structure of any well designed interface.
We have decided to use Google font Lato.
Font weight is an important typographic style that can add emphasis and is used to differentiate content hierarchy. Font weight and size pairings must be carefully balanced. A bold weight will always have more emphasis than a lighter weight font of the same size. However, a lighter weight font can rank hierarchically higher than a bold font if the lighter weight type size is significantly larger than the bold.
Lato font family provides a wide range of weights. However, only SemiBold, Regular, Light should be used for product design.
Line-height, traditionally known as leading, is one of several factors that directly contribute to readability and pacing of copy. Line-heights are based on the size of the font itself. Ideal line-heights for standard copy have a ratio of 1:1.5 (typesize : line-height). For example, a type at 16px/1rem would have a line-height of 1.5rem/24px (16 x 1.5). The exception to this rule are headings, which need less spacing and therefore have a line-height ratio of 1:1.25.
We recommend using two sizes for body copy. The first is UI specific. To maximize screen real estate we chose a smaller 14px / 0.875rem body copy size for the standard UI console. However, for areas that have prolonged reading, like Documentation, we use a larger body copy size of 16px / 1rem to enhance readability.
Set the reading environment to suit the reader. Wide lines of text are difficult to read and make it harder for people to focus. While there is no right way to measure the perfect width for text, a good goal is to aim for between 60 and 100 characters per line including spacing. Setting an optimal line length will break up content into easily digestible information.
Grid systems are used for creating page layouts through a series of rows and columns that house your content. Consistent use of a grid system provides the foundation for harmoniously and consistently positioning elements onscreen. Designing to the grid helps create an experience that facilitates understanding and brings order to the page.
In our grid system, we apply a center-aligned 12-column adaptive layout to the content. You can apply a fixed-width or a fluid grid layout. The fixed width layout has a max-width of 960px with a 20px gutter spacing. The fluid layout full-screen works better for screens that are data or interaction heavy.
Use the Spacing Scale when building individual elements. It includes minute increments needed to create appropriate spatial relationships for detail-level designs. This scale is applied and used within all DE components. The DE type stack specifies 14px for the base font size, which produces an 8px x-height. The x-height is halved to produce a 4px baseline. All text flows vertically along this baseline, creating a similar rhythm across all screens. This rhythm is created by the line height between each line of text and the margin between elements. This baseline convention naturally flows on to the rest of the grid system, which includes icons, components, and layout dimensions. Always try to align objects on the 8px grid, but where necessary, use good judgment to fine tune your designs to 4px. The 4 pixel baseline is there to allow more flexibility for line heights and smaller adjustments. Best practices
Layouts in our products are generally in an 8 or 12 column configuration. The simplest layout is a centered, single block that spans 8 columns. Alternatively, the layout can be extended to use the remaining 4 columns if there is a need for primary and secondary information. Best practices
@AlexJupiter we could do something similar to the dapp to show how those blocks such as (voting results, voting, blockchain representation) lay over the columns I have used lots of Atlassian content wo rite about those elements so i would need some help to rewrite it little bit and would also need to create my own images for that too Could you tell me how big is the ballot on the main page of the dapp where you see the list of ballot? how many columns it has? I am also not sure either what guidelines to create for the vertical spacing in the layout like between the header and the first ballot for example
@agazima in answer to your questions:
What naming are we going to use for typography; h1,h2,h3
Happy to discuss any proposition you might have here. However, I believe the small, medium (with many permutation) and large could work with what we have at the moment. I would also refrain from adding any other permutations of the typeface for now.
Should the font weight be included in the typography styles together with the size of the font?
I can't see how the font weight could be different from the typography without cuasing confusion and going against our current system. So yes, include everything together.
How detailed you want to go with describing one font style, example
I think these are great descriptions, however it is of course important to have an actual example there as well. The Joyent Design System does a good job of describing typographic choices if you want a good example.
Could i get help with what the grid that we currently have for dapp and design language should say about this grid?
I based the current grid off of the instructions in this article. I would encourage taking some of the explanations in this article and repurposing them for our design system (crediting where necessary).
we could do something similar to the dapp to show how those blocks such as (voting results, voting, blockchain representation) lay over the columns
Yes, I think this could definitely add something, however it might add a degree of complexity at the moment. Perhaps leave this for a further version of the design system? I am keen to get v1 done, which will be a bare bones design system we can then improve on.
Could you tell me how big is the ballot on the main page of the dapp where you see the list of ballot? how many columns it has?
Remember that the first version of the dapp will not have a list of ballots. However, when we do implement a list of ballots in a subsequent version, I would like the ballot list to be reflective of the ballot details group in this ballot dashboard template. So, that is 8 columns width.
I am also not sure either what guidelines to create for the vertical spacing in the layout like between the header and the first ballot for example
Please see this article that I also used for your questions on grids above.
- Typography
Where has all the below content come from?
@AlexJupiter
adding any other permutations of the typeface for now
What do you mean by permutation?
I can't see how the font weight could be different from the typography without cuasing confusion and going against our current system. So yes, include everything together.
Well, for example here you can see that font-sizes and font-weight are shown seperately http://carbondesignsystem.com/style/typography/overview so what would you suggest?
I think these are great descriptions, however it is of course important to have an actual example there as well. The Joyent Design System does a good job of describing typographic choices if you want a good example.
So you say that the font-size, font-weight and line height is more than enough and then would you add those descriptions as well like where they should be used? Btw is leading the line height?
I based the current grid off of the instructions in this article. I would encourage taking some of the explanations in this article and repurposing them for our design system (crediting where necessary).
Yeah but for example i don't know what scale you are using for the typography. Could you tell me how did you layout the columns and what is the gutter space between the columns, column width and the content width?
The content comes from two design guidelines http://carbondesignsystem.com/ and Atlassian Design guide
@agazima:
What do you mean by permutation?
Permutation = variation
Well, for example here you can see that font-sizes and font-weight are shown seperately http://carbondesignsystem.com/style/typography/overview so what would you suggest?
In my personal opinion I think the Carbon design system has made things unnecessarily complex. I think our general philosophy should be to: create as few constituents as possible that can be immediately added to the Figma component library, needing as little description as possible. Note: I use the word constituent here as a replacement for component because we have a specific component section, and also element to reduce confusion with Atomic design.
So the above philosophy means that we should have variations of typography in our design system that include:
Btw is leading the line height?
I believe it is, yes, however I would recommend googling this to double check.
i don't know what scale you are using for the typography.
As is the case in the design system, the paragraph text is 16px, and the title text is 24px. Those are the only sizes I created. You can see all info on the grids and columns by going here in Figma: As I said, I would encourage reading that blog post to follow those instructions to create a new grid and column. Hopefully we will arrive at the same conclusion!
Typography is used to create clear hierarchies, useful organizations, and purposeful alignments that guide users through the product and experience. It is the core structure of any well designed interface.
We have decided to use Google font Lato.
Line-height, traditionally known as leading, is one of several factors that directly contribute to readability and pacing of copy. Line-heights are based on the size of the font itself. Ideal line-heights for standard copy have a ratio of 1:1.5 (typesize : line-height). For example, a type at 16px/1rem would have a line-height of 1.5rem/24px (16 x 1.5). The exception to this rule are headings, which need less spacing and therefore have a line-height ratio of 1:1.25.
Set the reading environment to suit the reader. Wide lines of text are difficult to read and make it harder for people to focus. While there is no right way to measure the perfect width for text, a good goal is to aim for between 60 and 100 characters per line including spacing. Setting an optimal line length will break up content into easily digestible information.
Grid systems are used for creating page layouts through a series of rows and columns that house your content. Consistent use of a grid system provides the foundation for harmoniously and consistently positioning elements onscreen. Designing to the grid helps create an experience that facilitates understanding and brings order to the page.
In our grid system, we apply a center-aligned 12-column adaptive layout to the content. You can apply a fixed-width or a fluid grid layout. The fixed width layout has a max-width of 984px with a 24px gutter spacing and 60px of the column width. The fluid layout full-screen works better for screens that are data or interaction heavy.
Use the Spacing Scale when building individual elements. It includes minute increments needed to create appropriate spatial relationships for detail-level designs. This scale is applied and used within all DE components. The DE type stack specifies 16px for the base font size, which produces an 8px x-height. The x-height is halved to produce a 4px baseline. All text flows vertically along this baseline, creating a similar rhythm across all screens. This rhythm is created by the line height between each line of text and the margin between elements. This baseline convention naturally flows on to the rest of the grid system, which includes icons, components, and layout dimensions. Always try to align objects on the 8px grid, but where necessary, use good judgment to fine tune your designs to 4px. The 4 pixel baseline is there to allow more flexibility for line heights and smaller adjustments. Best practices
Layouts in our products are generally in an 8 or 12 column configuration. The simplest layout is a centered, single block that spans 8 columns. Alternatively, the layout can be extended to use the remaining 4 columns if there is a need for primary and secondary information.
Best practices
@agazima this is looking like a great start! However, all of the above is going to need to be put into Figma to close this ticket. Would you be able to do this here?
Once all the above is in Figma I should be able to provide more detailed feedback and we can carry that conversation on in here in an effort to close this ticket soon :).
@AlexJupiter i will be working on this from tomorrow on till friday ok? will update you. on friday i will also finish my internship so let's try to make it within those three days.
@AlexJupiter i have transferred all the info from here to Figma, could you have a look at it? Thanks
@agazima this is looking great!!! Well done. Are you happy for us to delete that old work at the bottom of the Figma file now?
So these bits here:
On suggestion on Typography:: we need descriptions in terms of why you would use each variation of the typography
Once those descriptions have been added, I am happy for this to be closed :)
@AlexJupiter Just deleted the unnecessary elements. I have a question in regard to naming the typographic styles. For example, there are several Medium styles and they are all called Medium, should we give some other symbol to the word Medium in order to distinguish different Medium styles? Like for example Medium 1,2,3,4 ? I have started adding the descriptions to the typographic styles as well. But I am not sure for example where the Regular style is used. Could you help me with that? And check the content of the other descriptions? Thanks Alex
We need to define the design system language in this Figma File.
This involves defining:
For reference, this blog post, might be useful.