If you have created a component you think would be useful to others or would like to make a suggestion, we want to hear from you.
We’ll be using Github issues to keep track of new component submissions, bugs, design feedback, and any other suggestions related to the design system. To help us understand the kind of contribution you want to make, we ask that you first submit an issue on Github.Create an issue
Guidelines for Filing an Issue
Here are a few guidelines to follow when creating a new issue:
- Go to the WVU Design System v2 source repository on Github .
- Click the “Issues” tab.
- Click the “New Issue” button.
- Under “Labels” select “enhancement.”
- Under “Assignees” select “Adam Glenn.”
- After you have filled out the issue form click the “Submit new issue” button to create your new issue.
- Once the issue is created it will move on to the review process.
Guidelines for Creating a Component
The easiest way is to create a component is by using utilities. This way the user can simply copy your HTML code and paste it into their project without having to integrate any Sass into their source files. If you want to make a custom pattern using name spaced classes, however, just include a Sass file that includes any custom mixins and variables. We will include your component in the Components section of this website, including any Sass code.
If you have developed a corresponding CleanSlate partial, we will add it to the WVU Design System theme, which users can reference just like any other partial listed on this site (see how to include shared partials in a template and how to include shared partials in the Super Template).
Note: You do not have to create a full-blown shared partial that functions like existing ones. All you need to do is submit the HTML and we will make it work with the system as a shared partial.
Creating an issue is just a way to start a conversation that is visible to the whole team. Anyone should feel free to create a new issue, but before a new submission moves on to a formal review process we’ll ask that each one includes:
- a fairly short descriptive title
- what will be gained by adding this design and will be lost if we don’t?
- a description of the design problem this component solves
- at least one of the following: screenshots/images of your rendered design, wireframes,
design mockups, links to
jsFiddle, etc., Axure mockups, iPhone photo of a napkin sketch.
- NOTE: If applicable, this should include a documented interaction flow, eg. states (hover, focus, click, drag…), error and success messages, etc.
- any other document, links, research you would like to include
- context (screenshots, links) if you have a specific use case for a proposed solution
If you are a developer and want help with your submission from a designer, make sure to mention that when creating your issue and someone from the review team will help pair you up with a designer. Same goes for designers that want help from a developer.
Once we have enough info, the team will do a review of the proposed design based on the following criteria:
- Usability — Is the pattern responsive? Does it follow commonly accepted best practices?
- Flexibility — Does the component meet the greatest number of use cases possible? In other words, is this a common pattern that occurs in lots of applications, or it solving a particular problem in one application?
- Accessibility — Is the pattern accessible to all intended audiences?
- Visual design — Is the contribution consistent with our visual style?
If the team decides to not move forward with the design submission, the issue will be marked as archived with an explanation of why.