design issueshttps://gitlab.coko.foundation/pubsweet/design/-/issues2018-01-29T07:20:03Zhttps://gitlab.coko.foundation/pubsweet/design/-/issues/1Color variables2018-01-29T07:20:03ZYannis BarlasColor variablesThe purpose of this issue is to come up with a common list of color variables for theming in pubsweet applications.
The idea is to compare the ideas that elife and coko/collabra have on the subject and find a "vanilla" list that organi...The purpose of this issue is to come up with a common list of color variables for theming in pubsweet applications.
The idea is to compare the ideas that elife and coko/collabra have on the subject and find a "vanilla" list that organisations can build on.
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|**Primary color**|`$color-primary`|`$color-primary`||This color is the branding main color|
|**Primary secodary**| |`$color-secondary`||This color is the branding secondary color|
|**Interation color**|`$hover-focus`|`$color-action`| | This color is the color used when hovering a button, a link.
|**Text color**|`$color-text`|`$color-text`| | Main color for the text, which should be inherited by all elements
|**Text secondary color**|`$color-text-secondary`| ||What is the use of this color?
|**Text placeholder / disabled color**|`$color-tex-placeholder`
|**Furniture color (dividers)**|`$color-text-dividers`
|**Background color hue**|`$color-text-background-hue`| | | Where is that variable used?
|**Success color**|`$color-success`|`$color-valid`
|**Attention color**|`$attention-color`| `$color-warning`|
|**Attention color**|| `$color-danger`
|**Attention color**|| `$attention-color`
|**light grey **|| || This color comes from editoria alignmentBox, need to be updated
|**grey **|| || This color comes from editoria alignmentBox, need to be updated
|**dark grey**||| | This color comes from editoria alignmentBox, need to be updated
|**whitergba**|| || This color comes from editoria alignmentBox, need to be updated (used for the inset of the alignmentBox)
@julientaq @Nick https://gitlab.coko.foundation/pubsweet/design/-/issues/2Typography variables2018-01-26T00:02:06ZYannis BarlasTypography variablesThe purpose of this issue is to come up with a common list of typography variables for theming in pubsweet applications.
## Size variables
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|-...The purpose of this issue is to come up with a common list of typography variables for theming in pubsweet applications.
## Size variables
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|**Body**|`$font-size-base-in-px`|`$font-size-base`||Base measure to set hierarchy from |
|**Scale**||`$font-size-scale`|| This variable is used to calculate the font size of all elements. Check this link for example http://type-scale.com/|
|**h1**|`$font-size-h1-in-px`|`$font-size * 2`| | This font-size should be based on the scale and the font-size-base, meanwhile, the calculation here is a example of how it could work. (using rem should achieve the same result, but break if we use different font for the body and for other elements, as x-height is different -- check the ressource: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
|**h2**|`$font-size-h2-in-px`| `$font-size * 1.6` |
|**h3**|`$font-size-h3-in-px`| `$font-size * 1.3` |
|**h4**|`$font-size-h4-in-px`| `$font-size * 1.0` |
|**h5**|`$font-size-h5-in-px`| `$font-size * 1.0` |
|**h6**|`$font-size-h6-in-px`| `$font-size * 1.0` |
|**p**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**li**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**ol**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**label (form)**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**a**|`$link-font-family`, `$link-color`, `$link-font-style`, `$link-font-weight`, `$link-underline-color` |||Link need some styling to be different from the content, let's add some variable that you can change for the link and see what's missing from there.
## Typefaces variables
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|**Primary font style**|`$font-primary`| | | Collabra font variables are named based on what the font is refering to. Check below.
|**Secondary font style**|`$font-secondary`
|**Contextual label**|`$font-contextual-label`
|**Date**|`$font-contextual-label-date`|||Treated as part of the label|
|**Section label**|`$font-section-label`
|**Teaser header**|`$font-teaser-header`
| *font family set for the whole app* |
|**Author font**| | `$font-author` | | This font will be used for all the element that the author work on: manuscript and form to submit.
|**Reviewer font**| | `$font-reviewer` | | This font will be used for all the element that the reviewer work on: reviewing draft and review letter.
|**Interface font**| | `$font-interface` | | This font is the one use for all the interface element
@julientaq @Nickhttps://gitlab.coko.foundation/pubsweet/design/-/issues/3Form variables2018-01-17T07:38:53ZYannis BarlasForm variablesThe purpose of this issue is to come up with a common list of variables for theming form inputs in pubsweet applications.
| Elife component name|Image of Elife component|Collabra component name|Image of Collabra component|Elife suggeste...The purpose of this issue is to come up with a common list of variables for theming form inputs in pubsweet applications.
| Elife component name|Image of Elife component|Collabra component name|Image of Collabra component|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|---|---|---|
|Button primary |[Button primary](https://drive.google.com/open?id=1HR9gkCFs7-0QR3pd7tvWE2H2R28uuQ56)|button|[Button](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#button) |`$border-radius`, `$color-primary`, `$primary-text-color`|`$button-background` ,`$button-borders`, `$button-border-radius`, `$button-border-color`
Button primary small|[Button primary small](https://drive.google.com/open?id=1vA2IEpBAxK6eYJGz1kNhqa81XONcwFlF)| *na* | *na* |`$border-radius`, `$color-primary`, `$primary-text-color` |`$button-background` ,`$button-borders`, `$button-border-radius`, `$button-border-color` | | the only change in the css would be the font-size (as every size should be in *em* for the atoms, so their size will be set by their parent)
Button secondary|[Button secondary](https://drive.google.com/open?id=1BEza2OI-iR1b1U0Y71LAVk3GjQD9ixmD)|Button secondary|[button](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#button)|`$border-radius`, `$border-width`, `$secondary-border-color`| `$button-background` ,`$button-borders`, `$button-border-radius`, `$button-border-color`
Text input|[Text input](https://drive.google.com/open?id=1nfPD9_QGnexMv5H_CnrMGrccHsIJUcGu)|Text field|[text-field](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#textfield)|`$border-radius`, `$border-width`, `$color-text-dividers`| `$border-color`, `$border-width`, `$background`
Text area|[Text area](https://drive.google.com/open?id=1TXdUuasJ50drfvy55XUg1f7WOA4uL0xr)|Text area| Not in the style guide yet|`$border-radius`, `$border-width`, `$color-text-dividers`
Select menu|[Select menu](https://drive.google.com/open?id=1rZc6Jz5ejI79iKNfQ6kOn7aGs4JEWs8i)|Menu|[Menu](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#menu)|`$border-radius`, `$border-width`, `$color-text-dividers`
Check box|[Check box](https://drive.google.com/open?id=1e4XVh1HJNeX8MXfOzAp9kDc7pjWb4RC2)|checkbox|[checkbox](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#checkbox) |`$border-radius`, `$border-width`|`$color-primary`, `$color-text`,|| checkboxes and radio buttons are a little tricky as it's using some specific css for collabra, and i think that elife ones relies on SVG. SVG could be a simple way to change element in the vanilla theme though.
Radio button|[Radio button](https://drive.google.com/open?id=1nDKOmjGgofqshe_sRqBugMj7YBnG1uX6)|radio|[radio](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#radio)|`$border-radius`, `$border-width`|`$color-primary`, `$color-text`
https://gitlab.coko.foundation/pubsweet/design/-/issues/4Spacing variables2018-06-20T16:14:57ZYannis BarlasSpacing variablesThe purpose of this issue is to come up with a common list of variables related to spacing for theming in pubsweet applications.
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|-...The purpose of this issue is to come up with a common list of variables related to spacing for theming in pubsweet applications.
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|Divider|`$border-width`, `$color-text-dividers`|
|Base spacing value (12px) || `$base-grid`
|Base spacing value x2 (24px) | | `$base-grid` * 2
|Base spacing value x4 (48px) | | `$base-grid` * 4
|Base spacing value x6 (72px) | | `$base-grid` * 6
|Line height spacing||||To be discussed
@Nick @julientaq https://gitlab.coko.foundation/pubsweet/design/-/issues/5Design tools2018-03-08T16:20:28Zjulientaqjulien@coko.foundationDesign tools## Requirements
* We need a common format for easily sharable assets
* We should be able to break larger components back down to atoms to build your own bespoke components
* It should be easy to contribute back to the master library/coll...## Requirements
* We need a common format for easily sharable assets
* We should be able to break larger components back down to atoms to build your own bespoke components
* It should be easy to contribute back to the master library/collection through upload or another method
* It should be easy to add components from the library/collection into your software for use
* It should be easy to view all available components, categorised by atoms, molecules, organisms. This should mirror the actual system for clarity between designers and developers
* We should be able to override vanilla styles with our organisation specific styles globally (a good constant trial for our theming system)
* Our assets should work with commonly used software so that others joining can get started easily
* We need to be able to add details to the component library per component to describe purpose and other details
## Proposed tools by category
#### Editing and creation
* inVision Studio (not yet available)
* Sketch
* Figma
* Adobe XD
* Marvel
* UX Pin
* Affinity Designer
#### Sharing and documenting
* Lingo
* Brand ai
* inVision design system manager
* UX Pin
* Marvel
#### Rapid prototyping
* inVision
* Adobe XD
* Marvel
* UX Pinhttps://gitlab.coko.foundation/pubsweet/design/-/issues/6Athens meet agenda (January 22-24, 2018)2018-01-25T23:57:57ZYannis BarlasAthens meet agenda (January 22-24, 2018)This is the agenda for the upcoming Athens meet.
## Theming
#### Make a list of components in code.
Display three different versions of them side by side, each set of them themed with the coko theme, the elife theme and the vanilla ...This is the agenda for the upcoming Athens meet.
## Theming
#### Make a list of components in code.
Display three different versions of them side by side, each set of them themed with the coko theme, the elife theme and the vanilla theme respectively.
The purpose of this is to use the same set of variables to create three different looks and to validate that the variables cover the requirements for these themes to be produced.
#### Vanilla theme
Discuss and write down the design principles and rationale behind the vanilla theme. This theme should be as generic as possible and created with the purpose of being extended by organisations to fit their own brand look without limiting them.
## Tools
Discuss and compare the tools that should be used to build our designs. If different teams decide to use different tools, we should make sure that the content produced in each tool is interoperable / compliant with the others.
Follow preliminary discussion in #5.
<hr/>
In general, the overall outcome of these three days should be that we solve the basics, so that we can move forward after it with fast and frictionless collaboration.
Will post a summary of the meeting here when we're done.https://gitlab.coko.foundation/pubsweet/design/-/issues/7Accessibility tools2018-03-22T15:44:57ZYannis BarlasAccessibility toolsWe should find tools that run accessibility tests.
It would be useful if we all ran our designs through the same tools, so that we can be sure that all themes meet the same set of standards.We should find tools that run accessibility tests.
It would be useful if we all ran our designs through the same tools, so that we can be sure that all themes meet the same set of standards.https://gitlab.coko.foundation/pubsweet/design/-/issues/8Scaling function2018-01-26T10:59:52ZYannis BarlasScaling functionAs discussed in the last meeting, we should build a scaling function for heading fonts.
The purpose for this would be to use the base font size (or another font size) and apply a specific scale on it to get the size of a specific head...As discussed in the last meeting, we should build a scaling function for heading fonts.
The purpose for this would be to use the base font size (or another font size) and apply a specific scale on it to get the size of a specific heading.
```
ratio = '4:5'
fontSizeBase = '12px'
fontSizeH3 = scale('h3', ratio, fontSizeBase)
```https://gitlab.coko.foundation/pubsweet/design/-/issues/9Hover / Interaction colors2018-01-26T00:21:18ZYannis BarlasHover / Interaction colorsIt is very common to use a variation of the color of an element when hovering over it to indicate interaction.
It becomes hard though to be generic.
If we were to define a `primaryColor`, then we'd also need a `primaryColorInteracti...It is very common to use a variation of the color of an element when hovering over it to indicate interaction.
It becomes hard though to be generic.
If we were to define a `primaryColor`, then we'd also need a `primaryColorInteraction`.
We could do the same for a `secondaryColor`, but if one were to introduce another one, then you'd need yet another variable for interaction.
A smarter approach might be to use a function on the components along the lines of [this one](https://css-tricks.com/snippets/javascript/lighten-darken-color/) that would shade the current background color of an element.
An alternative approach would be to have one interactive color for all elements, regardless of their current color.
It goes without saying that any of the above could be overriden in a custom theme, so this is more of a question of what is a more sensible default approach.https://gitlab.coko.foundation/pubsweet/design/-/issues/10Padding variable2018-06-20T16:16:16ZYannis BarlasPadding variableShould we add a `padding` variable to the theme, that is separate from the `gridUnit`, but could use potentially use it?Should we add a `padding` variable to the theme, that is separate from the `gridUnit`, but could use potentially use it?https://gitlab.coko.foundation/pubsweet/design/-/issues/11Focused elements2018-06-27T15:19:28ZYannis BarlasFocused elementsWe still need to figure out what happens to elements that are focused (eg. buttons, inputs etc).
Potential solutions are a variation on the current color, or maybe an outline like bootstrap does to its elements.We still need to figure out what happens to elements that are focused (eg. buttons, inputs etc).
Potential solutions are a variation on the current color, or maybe an outline like bootstrap does to its elements.https://gitlab.coko.foundation/pubsweet/design/-/issues/12Animations2018-01-26T00:26:52ZYannis BarlasAnimations`styled-components` [lets us](https://www.styled-components.com/docs/basics#animations) easily store animations in js.
It's worth thinking about creating and exposing some common ones so that they could be reused by different component...`styled-components` [lets us](https://www.styled-components.com/docs/basics#animations) easily store animations in js.
It's worth thinking about creating and exposing some common ones so that they could be reused by different components and applications.https://gitlab.coko.foundation/pubsweet/design/-/issues/13Box sizing2018-03-19T09:51:47ZYannis BarlasBox sizingShould we use `box-sizing: border-box` on the themes by default?Should we use `box-sizing: border-box` on the themes by default?https://gitlab.coko.foundation/pubsweet/design/-/issues/14Reset CSS2018-03-13T17:52:43ZYannis BarlasReset CSSThe theme should probably provide a `reset.css` file as well, removing browser default styles.The theme should probably provide a `reset.css` file as well, removing browser default styles.https://gitlab.coko.foundation/pubsweet/design/-/issues/15Vanilla theme variables2018-02-01T15:33:38Zjulientaqjulien@coko.foundationVanilla theme variablesHere are the chosen variables for a first draft of the variables.
Cf. https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md
## Colors
```css
colorPrimary: #205d86;
colorSecondary: #e7e7e7;
colorFurniture: #cccccc;
co...Here are the chosen variables for a first draft of the variables.
Cf. https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md
## Colors
```css
colorPrimary: #205d86;
colorSecondary: #e7e7e7;
colorFurniture: #cccccc;
colorBorder: #aaaaaa;
colorBackgroundHue: #f1f1f1; /*marginally darker shade of the app background so that it can be used to divide the interface when needed*/
colorSuccess: #005500;
colorError:#B50000;
colorText: #333333;
colorTextReverse: #ffffff;
colorTextPlaceholder: ##595959;
```
## Text variables
```css
fontInterface: "Noto Sans";
fontHeading: "Noto Sans";
fontReading: "Noto Serif";
fontWriting: "Ubuntu mono";
```
// scale is 1.125 with rounded values;
```css
fontSizeBase : 18px;
fontSizeBaseSmall: 16px;
fontSizeHeading1: 36px;
fontSizeHeading2: 32px;
fontSizeHeading3: 29px;
fontSizeHeading4: 26px;
fontSizeHeading5: 23px;
fontSizeHeading6: 20px;
fontLineHeight: 32px;
```
## Spacing
```css
gridUnit: 32px;
```
## Border
```css
borderRadius: 8px;
borderWidth: 1px;
borderStyle: solid;
```
## Shadow (for tooltip)
```css
boxShadow: 0 2px 4px 0 rgba(51,51,51,0.3);
```
## Transition
```css
transitionDuration: 2s;
transitionTimingFunction: ease;
transitionDelay: 500ms;
```https://gitlab.coko.foundation/pubsweet/design/-/issues/16[RFC] How to implement a table in a world of atoms and molecules?2018-02-13T17:22:43Zjulientaqjulien@coko.foundation[RFC] How to implement a table in a world of atoms and molecules?By definition, an atom is something that can be reused in another molecule.
Looking at the examples from @jure and Alex P. we see that there can be action inside the table, like removing a line (deleting a user for example), or change t...By definition, an atom is something that can be reused in another molecule.
Looking at the examples from @jure and Alex P. we see that there can be action inside the table, like removing a line (deleting a user for example), or change the status of another one. Therefore, the table will import atom or molecules inside its cells.
![tableBis2](/uploads/d55643dacbdb165791a9dc8a4d4f4d91/tableBis2.png)
![Image_Pasted_at_2018-2-13_14-31](/uploads/856f17dce0cf70344cc36098870b2a41/Image_Pasted_at_2018-2-13_14-31.png)
Tables are made of cells, which can be looked at like the atom of the molecule table. The problem of doing so is that, unlike a `label` for example, a cell will not be usable outside of a table.
Therefore, a cell is not an atom in itself.
More, based on [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table), tables can/should have:
- an optional `<caption>` element, *which is the title of the table*;
- zero or more `<colgroup>` elements *that let you describe the columns spanning of your table*
- an optional `<thead>` element *for the heading of each column*;
- zero or more `<tbody>` elements *which define the actual body of the table*;
- one or more `<tr>` elements *to define a row*;
- an optional `<tfoot>` element *for the footer rows of the table*
We can have a different atom for each type of cell. This would mean that we will have either an atom that will have all the styling for all the variants (aligned-right for numbers, background for the header cells), or we will have one atom for each need.
HTML is already well describing tables, using `thead`, `tr`, `td` and `th`. I believe that a well made set of css rules would be easier to use and maintain (even with responsible tables) than having all the options inside components.
More than that, the table are editorialized content, and therefore, will be harder to reuse amongst different applications.
That's why i would declare tables as a molecule that can use atoms inside it cells (like a `button` or a `link`).https://gitlab.coko.foundation/pubsweet/design/-/issues/17Design notes from the Coko meet up 26-28 feb2018-03-09T15:42:59ZNick DuffieldDesign notes from the Coko meet up 26-28 feb* Remaining xPub components on style guideist need to be brought into line with starter kit
* We have an agreed workflow from design to development
* Weekly design syncs between eLife, Coko and Hindawi for show and tells for work an...* Remaining xPub components on style guideist need to be brought into line with starter kit
* We have an agreed workflow from design to development
* Weekly design syncs between eLife, Coko and Hindawi for show and tells for work and new components
* New component designs are to be handed off to developers as gitlab issues. This includes a visual, description and spec annotations
* Accessibility requirements have been discussed for the xPub starter kit
* Checklist to be agreed at next design meeting
* We have an agreed tool set to measure accessibility
* Lighthouse by google
* A11YN
* We couldn't find a solution for file sharing after trying a number of approaches. This may not matter for now as it is unclear on what level we will share design assets
To do list for design
* Finish current component list as mentioned above
* Submit standard component values that are not part of customisation (width was referenced by yld)
* Agree accessibility check list for component contribution
* Review components/page layoutshttps://gitlab.coko.foundation/pubsweet/design/-/issues/18[RFC] Sharing assets: workflow and tooling2018-03-07T18:57:24Zjulientaqjulien@coko.foundation[RFC] Sharing assets: workflow and toolingTo be usable for developers and designers, all our assets should be delivered as a react component and as a editable mockup.
For example, in the case of a button:
- a button component, that you can reused in the code by adding a `<Butt...To be usable for developers and designers, all our assets should be delivered as a react component and as a editable mockup.
For example, in the case of a button:
- a button component, that you can reused in the code by adding a `<Button>` element;
- a graphic version of the component with editable text and styles.
Our goal is too have a single source of truth that we can offer to newcomers and that let designers and developers collaborate with as a little friction as possible. To achieve that, we need:
- an up-to-date styleguidist instance that let you see components (states, styles, behavior and animations);
- an up-to-date library that can be use in any tools that someone may want: from sketch to photoshop, amongst various other (pencil app, invision creator, or whatever comes next)
The only theme that needs to be share between designers is the starter kit.
### Some use cases that comes to mind:
- a designer needs to create a mockups using our atomic system. She can select the atoms she wants, import it into her application of choice and start building a new component.
- a designer is sending the mockup for his new component to his co-working developer and she must be able to see how the design must be implemented in terms of styling
- two designers share assets to build two different components based on the same atoms and molecules, and both are using two different tools.
### Basics
- Inclusivity first: no option should be set as the only way to contribute to the project. We must avoid any solution that would let someone out of the project.
- There is no really working options to share proprietary formats betweens applications. For instance, Figma knows how to open sketch file, but it does not render it as good as it was in sketch (not even talking about font). Sketch is unable to render figma files. Invision Creator has not been tested yet, as all the future tools.
- The only graphic format that stay editable is SVG. With the issues that the way it's exported from different applications are not totally set. For example, figma export the text as shapes, which means that you can not edit it anymore, you need to delete the text to add the new one -- also, it seems to be a bug that figma is trying to solve on their next svg export tool.
### Options
For now, three options are on the table:
- A shared folder with all the assets, ordered by atomic level, as svgs.
- A different asset library for each different tool we'd like to use (for each tool, a designer has to maintain the library and make it accessible).
- A tool used as a hub so we can share mockups and specs from different toolset in the same environment (@AlexPricop talked about https://zeplin.io as a tool to share the mockups from sketch/adobe tools/figma and let developer inspect the code). Zeplin only works on OSX and Windows but the idea would be to have a tool that let you share the documentation of all design with your developer.julientaqjulien@coko.foundationjulientaqjulien@coko.foundationhttps://gitlab.coko.foundation/pubsweet/design/-/issues/19Button component defaults2018-04-18T16:21:30ZYannis BarlasButton component defaultsDuring the Athens meet, we discussed that the following variables should be connected to the Button component.
`borderWidth`
`borderRadius`
`colorPrimary` (if the button is primary)
`colorSecondary`
`colorText` (applied on text ...During the Athens meet, we discussed that the following variables should be connected to the Button component.
`borderWidth`
`borderRadius`
`colorPrimary` (if the button is primary)
`colorSecondary`
`colorText` (applied on text for secondary buttons)
`colorTextReverse` (applied on text for primary buttons)
Is there any more values (beyond variables that would go into this element?)
eg. `min-width` comes to mind
The output of this should be a list of defaults for this element, so that the devs can translate to CSS.
---
#### Outcome
##### Primary button
Reference image
![primary-button_2x](/uploads/c972426bde704cf61d0d87fb20fcc959/primary-button_2x.png)
Default non-variable values
* Non at present
Primary button values
* background: colorPrimary;
* border-radius: borderRadius;
* border-width: borderWidth: 0;
* border-color: none;
* border-style: borderStyle;
* font-family: fontInterface;
* font-size: fontSizeBase;
* color: colorTextReverse;
* line-height: gridUnit;
* padding: gridUnit / 2;
* hover: 30% darker
* active: 30% darker
* disabled: opacity 50%
* press: 50% darker
* focus: colorPrimary, opacity 30%, width 3px
##### Secondary button
Reference image
![secondary-button_2x](/uploads/4bbe0b65d26a0e2005294717509a95a3/secondary-button_2x.png)
Default non-variable values
* Non at present
Secondary button values
* background: colorSecondary;
* border-radius: borderRadius;
* border-width: borderWidth;
* border-color: colorFurniture;
* border-style: borderStyle;
* font-family: fontInterface;
* font-size: fontSizeBase;
* color: colorText;
* line-height: gridUnit;
* padding: gridUnit / 2;
* hover: 30% darker
* active: 30% darker
* disabled: opacity 50%
* press: 50% darker
* focus: colorPrimary, opacity 30%, width 3pxNick DuffieldNick Duffieldhttps://gitlab.coko.foundation/pubsweet/design/-/issues/20Accessibility requirements2018-03-29T12:00:35ZYannis BarlasAccessibility requirementsIt was decided that a good first step here would be for each of the organisations to come up with their requirements with regards to accessibility, so that we can start a solid discussion of where vanilla should stand.It was decided that a good first step here would be for each of the organisations to come up with their requirements with regards to accessibility, so that we can start a solid discussion of where vanilla should stand.https://gitlab.coko.foundation/pubsweet/design/-/issues/21Components to be designed2021-05-05T20:39:31ZNick DuffieldComponents to be designed## Notes
* **Colors:** We should display these even though they are not components
* **Fonts:** Looks good. Are these atoms or just styles?
* **Typography:** We have headings and should also do p, label, ul, ol, li and other basic elemen...## Notes
* **Colors:** We should display these even though they are not components
* **Fonts:** Looks good. Are these atoms or just styles?
* **Typography:** We have headings and should also do p, label, ul, ol, li and other basic elements
## Components
| Category | Component | Comment | Non-var properties | Status |
|---|---|---|---|---|
| Atoms | Alignment box | What is this? || Clarification needed |
| Atoms | Attachment | What is this? | | Clarification needed
| Atoms | Avatar | | | To be done |
| Atoms | Badge | | | To be done |
| Atoms | Button | We have primary and secondary. Do the plain states need to be done? | min-width? | Review |
| Atoms | CenteredColumn | What is this? | | Clarification needed |
| Atoms | Checkbox | There is an animation on this. Have the variables been applied? | | Review |
| Atoms | Colorize | What is this? | | Clarification needed |
| Atoms | ErrorText | What is this? | | Clarification needed |
| Atoms | File | Deprecated: should we remove it? | | Clarification needed |
| Atoms | FilePicker | Where is this placed on the UI at the moment? | | Clarification needed |
| Atoms | Flexbox | Is this an atom? | | Clarification needed |
| Atoms | Heading | Do we have the other heading sizes? Some variables are incorrect | | Review |
| Atoms | Icon | | | To be done |
| Atoms | Link | Looks fine. Is this done? || Review |
| Atoms | Menu | Looks fine. Should we name this select menu. I think of menu as the header type patterns. || Review |
| Atoms | Radio | There is an animation on this. Have the variables been applied? || Review |
| Atoms | Section | What is this? || Clarification needed |
| Atoms | Spinner ||| To be done |
| Atoms | StateItem | What is this? || Clarification needed |
| Atoms | Tags | What is the difference between a tag and a keyword? || To be done |
| Atoms | TextField ||| Review |
| Atoms | UploadButton | How is an upload button different from a button? || Clarification needed |
| Atoms | UploadingFile | What is this? || Clarification needed |
| Atoms | ValidatedField ||| Review |
Molecules | AlignmentBoxWithLabel | What is this? || Clarification needed |
Molecules | AlignmentTool | What is this? || Clarification needed |
Molecules | AppBar ||| To be done |
Molecules | Attachments | What is this? || Clarification needed |
Molecules | CheckboxGroup ||| To be done |
Molecules | EditableValue | What is this? || Clarification needed |
Molecules | Files | What is this? || Clarification needed |
Molecules | FileUploadList ||| To be done |
Molecules | PlainButton | Is this a molecule? How is it different too the PlainButton in Buttons? || Clarification needed |
Molecules | RadioGroup | Do we have a vertical one too? || To be done |
Molecules | StateList | Are these breadcrumbs? || To be done |
Molecules | Steps | Where are the atoms for this?|| To be done? |
Molecules | Supplementary | This looks like a molecule made of files? The name doesn't suggest a connection || Clarification needed |
Molecules | Upload | Is this a molecule? How does it differ in use from UploadButton? || Clarification needed |
Molecules | YesOrNo | Isn't this just a RadioGroup? || Clarification needed |https://gitlab.coko.foundation/pubsweet/design/-/issues/22Add a "warning" color2018-06-27T11:31:48ZAanand PrasadAdd a "warning" color`ValidatedField` display a _warning_, as distinct from an _error_:
![Screen_Shot_2018-03-12_at_14.34.41](/uploads/37fa05d95ccdb6e7e2eb7d3ba5022b7b/Screen_Shot_2018-03-12_at_14.34.41.png)
There's no color in `VARIABLES.md` for this, so ...`ValidatedField` display a _warning_, as distinct from an _error_:
![Screen_Shot_2018-03-12_at_14.34.41](/uploads/37fa05d95ccdb6e7e2eb7d3ba5022b7b/Screen_Shot_2018-03-12_at_14.34.41.png)
There's no color in `VARIABLES.md` for this, so @g-sam added one in https://gitlab.coko.foundation/pubsweet/pubsweet/commit/c2a1d54bc7f077f39ab5a932fc18783493dc4eff. We shouldn't have discrepancies between the official variables and what's in the default theme, so we should either remove the warning function or add `colorWarning` to `VARIABLES.md`.
Thoughts?Nick DuffieldNick Duffieldhttps://gitlab.coko.foundation/pubsweet/design/-/issues/23Workshop ideas2018-03-21T18:12:52ZNick DuffieldWorkshop ideasIdeas board for our next stages in pubsweetIdeas board for our next stages in pubsweethttps://gitlab.coko.foundation/pubsweet/design/-/issues/24Subgridunit variable2018-06-28T09:45:27ZYannis BarlasSubgridunit variableThere seems to have been a discussion that was not conclusive about including a `subGridUnit` variable in the themes.
This seems however, to already exist in the default theme's code (https://gitlab.coko.foundation/pubsweet/pubsweet/bl...There seems to have been a discussion that was not conclusive about including a `subGridUnit` variable in the themes.
This seems however, to already exist in the default theme's code (https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/default-theme/src/index.js#L39).
Let's have a final discussion about this.
I think we should either standardize this or remove it from the themes.https://gitlab.coko.foundation/pubsweet/design/-/issues/25Accessibility design guidelines2019-04-02T14:41:58ZYannis BarlasAccessibility design guidelinesShould we have a short guideline on how design can affect accessibility?Should we have a short guideline on how design can affect accessibility?Alex PricopAlex Pricophttps://gitlab.coko.foundation/pubsweet/design/-/issues/26Define values for Coko theme2018-04-10T09:47:33ZYannis BarlasDefine values for Coko themejulientaqjulien@coko.foundationjulientaqjulien@coko.foundationhttps://gitlab.coko.foundation/pubsweet/design/-/issues/27Text Area2018-07-27T15:53:39Zjulientaqjulien@coko.foundationText AreaHere are the design for the text area based on @Nick's button (#19) and the already live [text input](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#!/TextField)
![textArea](/uploads/856e78d3021e3a8ad5bc8dac975a515f/textArea...Here are the design for the text area based on @Nick's button (#19) and the already live [text input](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#!/TextField)
![textArea](/uploads/856e78d3021e3a8ad5bc8dac975a515f/textArea.png)
- background: white;
- border-radius: $borderRadius;
- border-width: $borderWidth;
- border-color: $colorFurniture;
- border-style: $borderStyle;
- font-family: $fontWriting;
- font-size: $fontSizeBase;
- color: $colorText;
- line-height: $gridUnit;
- padding: $gridUnit / 2;
- hover: border-color: $colorPrimary, border-width 3px
- disabled: opacity 50%
- active: border-color: $colorPrimary, border-width 3px
- focus: border-color: $colorPrimary, opacity: 30%, border-width 3px
`:active` and `:hover` have a border with the primary color.
`:focus` get a lighter primary color for the border, in order to be less disturing while writing.
Did i miss some?
Thanks!https://gitlab.coko.foundation/pubsweet/design/-/issues/28styleguide-demo.coko.foundation -- left hand frame does not work on Safari2018-04-20T14:42:54ZBrian Tinglestyleguide-demo.coko.foundation -- left hand frame does not work on SafariSafari Version 11.1 (13605.1.33.1.2) on OS X 10.13.4
Hi, When I try to browse http://styleguide-demo.coko.foundation on safari, when I try to scroll down on the left frame, as soon as I mouse over a link text, the left frame jumps back ...Safari Version 11.1 (13605.1.33.1.2) on OS X 10.13.4
Hi, When I try to browse http://styleguide-demo.coko.foundation on safari, when I try to scroll down on the left frame, as soon as I mouse over a link text, the left frame jumps back to the top, undoing my scroll. This makes it impossible to select the lower links (unless you filter for what you want)https://gitlab.coko.foundation/pubsweet/design/-/issues/29"boxshadow" or "dropshadow"? - 2 names for the same thing2018-06-28T15:52:36ZJen Spencer"boxshadow" or "dropshadow"? - 2 names for the same thingIn [`VARIABLES.md`](https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md#shadow) the shadow variable is called `dropShadow`, so this is the same name being used in [eLife's designs](https://projects.invisionapp.com/sha...In [`VARIABLES.md`](https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md#shadow) the shadow variable is called `dropShadow`, so this is the same name being used in [eLife's designs](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926980).
But the name used in all the themes (e.g.[the Coko theme](https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/coko-theme/src/index.js#L59) & [eLife theme](https://github.com/elifesciences/elife-xpub/blob/develop/client/elife-theme/src/index.js#L44) is actually `boxShadow`.
It's [now being changed in eLife's theme](https://github.com/elifesciences/elife-xpub/pull/233/files#diff-b997819fc7f534ccbc7ed0f02dc3aa50R58) to `dropShadow`, to match our design document.
Which do you fancy? :smile:https://gitlab.coko.foundation/pubsweet/design/-/issues/30separate line heights for each heading?2018-07-02T10:55:31ZJen Spencerseparate line heights for each heading?In the [latest eLife theme](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926983) we have line heights for each h1, h2, etc, as well as fontSizeBase & fontSizeBaseSmall.
This has now been added to [the code for the eLif...In the [latest eLife theme](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926983) we have line heights for each h1, h2, etc, as well as fontSizeBase & fontSizeBaseSmall.
This has now been added to [the code for the eLife theme](https://github.com/elifesciences/elife-xpub/blob/develop/client/elife-theme/src/index.js#L33-L40)
Is this something you would want to replicate in pubsweet?Yannis BarlasYannis Barlashttps://gitlab.coko.foundation/pubsweet/design/-/issues/31Specify multiple gridUnits?2018-06-25T23:26:47ZJen SpencerSpecify multiple gridUnits?As I understand it, pubsweet is intending to change the `gridUnit` variable to `6px`? This has already happened in the eLife theme.
We also have [XXS, XS, S, M, L, XL & XXL for "vertical spacing"](https://projects.invisionapp.com/share/...As I understand it, pubsweet is intending to change the `gridUnit` variable to `6px`? This has already happened in the eLife theme.
We also have [XXS, XS, S, M, L, XL & XXL for "vertical spacing"](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926984), which have been added to [our theme's code](https://github.com/elifesciences/elife-xpub/blob/develop/client/elife-theme/src/index.js#L44-L50)
Just feeding info back up, in case others would like this type of sizing, rather than computing `gridUnit * 4` manually in each place in the code.
Personally, I'm unsure about XXS, XS, etc as variable names & would be more inclined to go with something like 1, 2, etc as we do with headings - see [this comment in the eLife issue](https://github.com/elifesciences/elife-xpub/issues/217#issuecomment-398738586) but perhaps this is a popular convention?
Relates #4, #10 & #24 https://gitlab.coko.foundation/pubsweet/design/-/issues/32layout (grid?) - where should responsibility lie for the space between compon...2018-07-27T17:23:42ZJen Spencerlayout (grid?) - where should responsibility lie for the space between components on a page?Right now, the space between components on a page seems to be achieved by having `margin-bottom` on each of the individual atoms. (Is this correct?) Therefore each individual component bears the responsibility for how much space exists b...Right now, the space between components on a page seems to be achieved by having `margin-bottom` on each of the individual atoms. (Is this correct?) Therefore each individual component bears the responsibility for how much space exists between itself and the component below it on a page.
If a specific page calls for more/less margin than an atomic component has by itself, then the normal `margin-bottom` needs to be overriden. Having layout responsibility being shared across multiple levels of nesting makes it a little harder to reason about what needs overriding.
Also, how would we achieve spacing between the top of a page, or the navbar, and the first component on a page (e.g. a `TextField`)? The responsibility could lie with:
- the `TextField` on this specific page e.g. adding `margin-top` to this `TextField` only
- adding `margin-bottom` to whatever is above it (such as the navbar)
- use flexbox/grid/etc to wrap all components and use `space-around`
No matter which we choose, responsibility for the spacing between the navbar and the TextField lies at the page level, but spacing between the TextField and the component below it lies with the TextField itself. Would it not be easier to reason about, if the spacing between components lived on the same level?
What do you guys think of leaving margins off each individual component & therefore leaving the responsibility for spacing between each component to the page level (& molecule level)?https://gitlab.coko.foundation/pubsweet/design/-/issues/33[RFC] migrating from this repo to pusbweet?2018-08-03T09:44:46ZJen Spencer[RFC] migrating from this repo to pusbweet?At the Pubsweet Meet, it seemed like a common theme that development was happening faster than design, which obviously isn't ideal for anyone! One of the many things that seems to be causing this is that designers and developers are ofte...At the Pubsweet Meet, it seemed like a common theme that development was happening faster than design, which obviously isn't ideal for anyone! One of the many things that seems to be causing this is that designers and developers are often having conversations very separately from each other.
Some developers weren't even aware that this repo existed. So some of the good discussion that has happened in issues on here hasn't necessarily translated into a reality for our applications. For example, we've each dealt with grid layout, hover states, etc, in whatever way feels appropriate for our apps.
At the Meet, I proposed that we raise issues about the creation of new components directly on the `pubsweet` repo, so that all 4 xpubs have greater visibility over what other xpubs are creating. But I would hate to see this turn into devs dominating the design decisions. So it's essential that devs don't end up discussing things on pubsweet's issues without designers weighing in. My hope is that pubsweet becomes a single source of everyone's contributions.
But at the Pubsweet Meet, it was also brought up that it might be daunting for designers, especially for new starters, to jump into the huge melee of issues on the pubsweet repo? Hopefully this can be solved via labels on the pubsweet issues, so that the huge number of issues can be filtered & only the relevant issues are shown.
Perhaps there are also things that designers would prefer to discuss with each other _first_, before being assaulted by developer's questions about implementation? So I would love to know what you all would think of moving the readmes in this repo into pubsweet's wiki pages & raising design repo issues directly in pubsweet instead?
Is there anything I'm misunderstanding about how this repo is being used, or why it's preferable to have these in separate places? Because I'm concerned that separating these 2 groups' discussions is negatively impacting designers' concerns & decisions actually making it into code.