-
Notifications
You must be signed in to change notification settings - Fork 103
Contributing to PF Design: Checklist
As part of the PatternFly design sprint, you will be tasked with designing a component, enhancement or demo. The main task requires you come up with a design, iterate on it, and ultimately deliver a set of mocks and corresponding specs for implementation.
There are many things you can do to help you come up with a design, including the following:
- Looking at how other design libraries address the issue (for example, Carbon and Material design)
- Google search for other general examples
- Talk to other the creator of the design issue to see if they had any thoughts in mind
- Talk to other designers for ideas/collaborative ideation
After gathering ideas, you can create preliminary designs to start collecting feedback.
Once you have initial ideas and mocks to show, share them with others to get initial feedback.
You can share your designs at the following forums:
- UXD Wide PatternFly Design Share (Every 3 Wednesdays at 11am EST) [agenda]
- PF Design sub team PatternFly Share & Sync (Every Thursday at 11am EST) [agenda]
You can also share your designs with the creator of the issue to see if it meets expectations. In reality, you can get feedback from whomever you want, but the two forums listed above are where you will be able to communicate with the most people in one spot.
Below is a checklist for creating effective mocks and corresponding specs. Note that although our team mostly uses Sketch (and that is the tool where you will find a PatternFly component symbol library), mocks can be created with any design tool of your choice.
-
Create mocks to show the design. Mocks should just be a visual representation of what the component/demo/pattern should look like, and how it should work. It should include:
- Explanation of interaction/how it works
- Different states (active, hover, disabled)
- Responsive behaviors - consider and explain how it should react as the screen gets smaller and smaller. Typically, the minimum screen size to account for is 360px width - standard mobile size.
- Non-ideal scenarios (wrapping/truncating etc. What happens when the text is extremely long? Does it truncate or wrap? What if it’s a long string with no spaces? Consider things of this nature.
-
Add specs to your mocks to clarify design. Specs should include:
-
Component names (if they aren’t obvious). Which components you used to create your demo or enhancement.
-
Component variations (for example, primary button vs. secondary button)
-
Spacers (if it’s a new component) Show correct spacing between elements in your design using the Spacer Sketch symbols. See below for spec example with spacers.
-
Layout used (if applicable)
-
Variable name (if custom changes made)
-
Iconname (if non-obvious icon)
-
Styles/colors used (using CSS variables, not HEX values):
- [Text] colors (For example, --pf-global--primary-color--100)
- Background colors (For example, --pf-global--BackgroundColor--200)
- Shadows and borders (For example, --pf-global--BoxShadow--lg)
Unsure what variable you used? Check the Sketch layer style selected. Otherwise, compare the HEX Value to the color list to find the correct variable. Try not to just put the HEX Value - devs use variables not HEX values.
-
Tips for creating specked mocks: If you are using Sketch, you may use this Sketch Symbol library that contains annotations that you can use to add specs to your mocks. Using this Sketch library and the symbols in it can help create consistency around our handoff process.
Once you have all of this, you should comment on the design issue, with the final mocks and specs (make it clear that it’s the final spec).
If your design issue is simple, you can just add a screenshot of your design to your issue, along with text to add specifics.
If your design issue is more complicated, it is helpful to link to a mockup file in Sketch Cloud to show interactions, added descriptions, and specs all in one place.
Once your issue is ready the PF Design Lead will create a core issue for it, and will ensure that the link to your design is included in the core issue - and that the core issue is linked to the design issue. They will also ensure that the dev knows you were the one to work on the issue so that you can be contacted for any needed clarifications.