GitLab

July 25-26, 2018

Agenda

During this pubsweet meet, some questions were raised:

• Should there be a pubsweet-design repo only for design questions? Jen stated that, for now, all the discussion that take place in the repo are more about dev implementations than proper design discussions and should happen in the pubsweet general repo. Are we agreeing to that? Or should designers be more included in the pubsweet repo to discuss all the things they can have a idea about?
• Should we have mockups for all the existing pattern that we can find in the stylguidist, as it seems that it's not easy to use for the designers? If so, where should they be?
• What would be useful to have for designers that we don't have yet? (svg or png mocks to share, newcomer designer FAQ and Best practices documentation? etc.)
• The pubsweet default theme (as known as pubsweet-UI) is now made from the styleguidist: when a dev implement a pattern, the theme switcher in styleguidist can show the same pattern with the default theme. This is useful for developers as they can build prototype app quickly. Should we have a proper UI-toolkit so a designer can make its own layout/mockups using the default theme? (would that be useful to anyone?)

Meeting notes

What we managed to do so far:

• Create a common vocabulary amongst developers and designers in the pubsweet community;
• Build a theming engine that let any designer build its own visual language, using variables and override;
• Start a default theme that can be used as is for new comers (Hindawi used the default theme to build the first prototype iteration of their app).

June 26, 2018

Agenda

• How to handle headings and line height? (eg. h1/2/3 font might be larger than line height)

Meeting Notes

• We talked about the relationship between different font sizes and line height, and came to the conclusion that for each font variable, we need a corresponding line height variable.
• We validated that elements don't set their own margins and paddings, but it is up to their parent components to space them correctly.
• Nick guided us through eLife's people picker wireframes.

June 13, 2018

Agenda

• Close gridunit discussion: Should we use a small value that always gets multiplied?
• Should elements themselves add margin and padding above / below them or should the element's parent take care of this?
• Nick show and tell eLife component guide, comms control and form wizard

Meeting Notes

• Gridunit: Keep a small-value variable (eg. 8px) and multiply it as needed.
• This is up to the devs to implement as they wish, as long as the door is left open for designs to fall nicely on the grid.
• Introduce colorWarning to the default theme, as we now have a use case.
• Perhaps introduce colorTextSecondary as a variable (perhaps put this on next week's agenda?)

May 3, 2018

Agenda

• Set up a second design workshop (real life or web) as soon as possible for everyone to catch up and to go through the components that remain to update for pubsweet

Meeting notes

• Design review of the appbar for pubsweet UI. This pattern include:
  • big screen bar with a list of navigation links and login button;
  • atom for the app navigation menu with two options: slide in from the left or right bottom the navbar (responsive version of the menu in the AppBar);
  • a floating list of action that could be used anywhere in the app (in the demo, it was a list of multiple action regarding the user: log-out, update preferences, etc).
• Design/Code review of the first implementation of the button component, in pubsweet UI.
• We also mentionned the Dropdown menu issue: https://github.com/elifesciences/elife-xpub/issues/45#issuecomment-383931608

April 17, 2018

Agenda

• Decide on the use of naming convention with gridUnit on the starter-kit (check below)
• Subgrid: decide if we stick to the smaller unit grid system or on a line-height based grid.
• Update on buttons (#19) and discuss next element to design.
• Update on buttons: @julientaq can show example of states for the buttons and how it could be implemented on the theme if we all agreed. (simple box-shadow on focus and hover on clic).
• Frequency of design meetings: We have had just over a months worth, now might be a good time to evaluate how often we need them.
• Accessibility checklist: eLife will be meeting A and AA requirements from this list https://www.w3.org/TR/WCAG20/ when sharing back to the vanilla kit do we all agree that this suitable for now?
• Variables: Are these suitably locked down for eLife to build against?
• eLife: component build next steps

Meeting Notes

• Whether we use subGridUnit or gridUnit is more of a developer question, as long as we provide a way to stay on the grid.
• Button discussion has been closed on gitlab, so it's up to Yannis to implement it on the styleguide now.
• The driver for next elements to work on will be organisational needs from now on (instead of collectively deciding on a set), as we're all trying to deliver software at the moment.
• The process for changes or introduction of new elements will be to show the new/changed element to the design group, have it pass and get the devs to introduce these changes into the styleguide. The important part would be to avoid prolonged discussions about minor points. We can always introduce more changes later.
• Variables seem to be satisfactory to everyone so far, so we can safely consider them good for use.
• Accessibility standards checklist will be the list posted above by Nick.
• The frequency of the design workgroup meets from now on will be every other week, so that there is more to show and we don't end up stretching people's already tight schedules.
• The phrase "starter kit" is from now on banned. Use "pubsweet ui" or "styleguide" instead. Penalties apply.

April 3, 2018

Agenda

• Sub grid - do we need to set these values
• Vertical space. Should we be setting our line-height based on our smallest measure rather line height (8px for instance)? What are the pros and cons?

Meeting notes

Subgrid

Idea is to set the minimal value for the grid on the smallest increment to stick to only keep one maths formula (you don't have to mix division and multiplies). Therefore, the $fontLineHeight will be set as a calculation ($fontLineHeight = $gridUnit * 4), this is still pending as the meeting was shortened. For example, this is the code for the button, which mixes multiply, division, gridUnit and subGridUnit:

  min-width: calc(${th('gridUnit')} * 4);
  height: calc(${th('gridUnit')} * 2);
  padding: 0 calc(${th('gridUnit')} / 4);
  margin-right: ${th('subGridUnit')};

Naming convention for gridUnit

Idea is to use simple words to define the amount of space between elements. For example:

For now, it seems that it's not needed by all the stakeholders, and thus should not be implemented in the starter-kit. This need to be decided on the next meeting

March 29, 2018

Agenda

• Padding variable, final decision
• Warning color
• Box sizing: border-box by default?
• Accessibility guidelines for designers
• Is accessibility testing a design or dev concern?
• Base grid measure value for starter kit. Is 32px a sensible choice to suit a variety of screen sizes?

Meeting notes

Padding variable, final decision

• Not a variable for now. If we need to address it in future we will revisit the issue.

Warning color

• Not a variable for now. If we need to address it in future we will revisit the issue.

Box sizing: border-box by default?

• Yes

Accessibility guidelines for designers

• 2 week goal set for contribution to accessibility checklist. Alex, Julien, Nick + anyone else. Julien to send articles for reference. Dev section and design section. Some tests can be automated, some are manual and we need to agree tools and procedures

Is accessibility testing a design or dev concern?

• Tests are the responsibility of component creators. Both design and dev.

Base grid measure value for starter kit. Is 32px a sensible choice to suit a variety of screen sizes?

• We all agree this is too big
• Sub grid - to be discussed next week
• Further discussion needed for vertical. Should we be setting our line-height based on our smallest measure 8px for instance. Pros and cons

March 21, 2018

Agenda

• Accessibility discussion. Where are we at? Next steps
• Review of button issue No 19
• Padding variable. Do we need it?

Meeting notes

• All orgs agree that they should meet WCAG 2.0 AA standards. Dev work on this has already started.
• There's a pending discussion on hover/focus/active status for the button, but that should be resolved soon (before the next meet)
• Most likely not using the padding variable, but pending final confirmation from all teams.
• It was decided that we should sync up on whether a subGridUnit variable should go into the theme or not.

March 14, 2018

Agenda

• Glossary of terms (pubsweet vs xpub, starter kit vs pubsweet-ui etc)
• Elife xpub wireframes show n' tell
• Introduction of grid library for component development
• Topics and dates for next IRL meeting

Meeting notes

• We decided that we should contribute to expand the current pubsweet wiki instead of creating a separate glossary of terms in the design channel.
• The grid library is not a designer concern per se, but it was brought up so that it's on everyone's radar that there is a plan to use that.
• We skipped the workshop subjects discussion, as not everyone in the group was present in the meeting. It is probably happening in May.
• Elife showed us their current version of the xpub-elife wireframes.

March 7, 2018

Agenda

This first meeting established the new design workgroup weekly meeting, which happens so that we can keep track of what we are working on, as well as what comes next.

To discuss:

• Update on tooling: what can we share between designers, and how can we work together.
• Briefing for the next phase:
  • component redesign for starter-kit: who is tackling it? and how is the work reviewed?
  • update the styling for starter-kit: what is the design to development workflow?
• Small update to catch what we´re workin on, so we know

Meeting notes

Tooling & sharing of design assets

There doesn't seem to be a good way to share design assets between different tools such as Sketch, Figma etc. The best candidate for achieving this was exported SVGs, but each tool seems to have its own inconsistencies with the format, which puts a blocker on assets being imported to other tools.

The outcome is that the attempt to find a sharable format is put on hold, at least for now. As long as communication happens between designers and their ideas are shared, it is not an absolute necessity for the assets themselves to be common at this moment.

It will be good to use gitlab for disucssion and sharing of ideas and mocks, so that there is a written record of design decisions. As far as communication of design choices to developers is concerned, gitlab seems like a natural fit as well. The specifics of how assets and their technical details are communicated to devs is up to each organisation to sort out internally.

Pubsweet UI component library

We need to go through all the elements in the library and make sure they have sane default values and listen to the correct variables from the theme. We'll start with the elements that the group had gone through in the Athens meet, then keep tackling them in chunks that can be delivered to developers, so that they can be implemented in parallel.
@Nick is taking the lead on this

Next IRL meeting

We discussed what the next in-person meeting agenda could look like.
Current candidates are:

• Reusable and sharable layouts
• Reusability of more complex components
• Sharing design ideas for reviewer discovery and assignment

It currently looks like the meeting will take place in May.

February 26-28, 2018 (Coko meetup London)

Discussed

• 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 progress show and tells including new components designed
  • 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 layouts