design issueshttps://gitlab.coko.foundation/pubsweet/design/-/issues2018-07-02T10:55:31Zhttps://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/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/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/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/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/26Define values for Coko theme2018-04-10T09:47:33ZYannis BarlasDefine values for Coko themejulientaqjulien@coko.foundationjulientaqjulien@coko.foundationhttps://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/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/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/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/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/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/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.