usajobs / design-system Goto Github PK

The nav should allow for keyboard interactions to move within the nav, toggle the nav. The list from the Saleforce design system is a good place to start:

• Arrow keys cycle focus through menu items (you should use JS to disable focus for any disabled items)
• Tab key closes menu and moves focus to the next focusable element on the page
• Esc key closes menu and moves focus back to the menu trigger
• Any character key moves focus to the next menu item that starts with that character, if applicable

I thought we had agreed to not truncate the title and agency on the server side and that dev was working on a solution in CSS but, alas, that is not what is happening. A bug has been filed internally but, I need to handle this truncation in this component in the CSS. I should done so originally.

Define the visual treatment of an active nav item both in the top level menu and the secondary menus.

We sense we want to have more than the 3 breakpoints the Standards supply and thus a revised grid of our own. This is awaiting discussion with dev next week.

Possible breakpoints (I've bolded the breakpoints of the U.S. Web Standards):

Smartphone

320px - iPhone4/5 portrait, Galaxy S3/4 portrait
360px - Galaxy S5 portrait
375px - iPhone 6 portrait
414px - iPhone 6+ portrait
480px - iPhone 4 landscape
568px - iPhone 5 landscape
600px
640px - Galaxy S3/4/5 landscape
667px - iPhone 6 landscape
736px - iPhone 6+ landscape

Tablet, Laptop, Desktop

768px - iPad portrait
800px
1024px - Tablet landscape
1041px
1167px
1200px
1224px
1280px
1324px
1920px

By no means would we include all of these (I hope that is obvious). We should absolutely let the content decide where we need a breakpoint. Also, we should follow the lead of the U.S. Web Standard breakpoints and not make ours device-specific because it is foolhardy to try and keep up with the plethora of devices. Here is an article that makes that point eloquently:
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints

That said, I've found in past design systems the need to have minor breakpoints:
http://bradfrost.com/blog/post/7-habits-of-highly-effective-media-queries/#major-minor

The sizes greater than 800 come from here (give it time to load):
http://gs.statcounter.com/#console-resolution-na-monthly-201410-201509

My recommendation is the following:
480px
600px
1024px
1200px
1920px

My rationale is that the space between 600px and 1200px is too vast and includes an orientation change (portrait to landscape). We could choose to detect this with an orientation media query but I'd prefer the 1024px breakpoint. Also, treating everything above 1200px as a large desktop viewport misses an opportunity to take advantage of the increased space. Of course, it also means we have to generate designs for that space. Given that it has become such a common size (see link above) that strikes me as a worthwhile endeavor.

Min and I agree that the page gutter size of 30px on both sides is too constricting in narrower viewports. We'd like to cut this in half on both sides, which will match production as well, until the $ML breakpoint or perhaps even $MLL.

This tracks the work to create the Logo and Logo usage component of the design system.

We need to add a secondary nav component to the design system to handle cases where we have navigation with a section. A prime example is within profile where we, sadly, have a double hamburger (a crime against humanity). Our initial take is to use the priority+ pattern with a menu:

http://codepen.io/Dreamdealer/pen/waVzmK

However, we're going with a the more minimal text style:
http://codepen.io/bradfrost/pen/orJwL/

As a developer, it would be great to be able to contribute to the main site. Is there a plan to start a new repository?

Even if you aren't able to publish the code, it would be nice to have a central place to file issues.

Apologies for filing this here-- I would have put it under the Open Source Policy, but issues is disabled for that repo.

We want to break out the Application Guide prototype as that is a distinct project onto itself. We simply included it here for the sake of expediency.

We have a slightly different disabled button state in application guide (because it sits on a grey background). We need to add it to our buttons page.

We did the styles for the attached message but, I failed to demonstrate it in the design system.

There is a mandate to keep the JOA under 5 printed pages. We don't currently have a print stylesheet and our move to a new typeface has exacerbated this problem.

Tasks

Define a print stylesheet for the JOA.

I did something odd in the prototype for Application Guide by making the font-weight change at the ML breakpoint. It should have been bold for the current step only.

18F recommends using a rem fallback to px for font-size (and we're using rem in spacing.scss as well). However, it doesn't seem to be implemented in the Standards yet and I don't see an issue for it (I'll raise it with them soon). In the meantime, we should build our own sass mixin to give us fallback px values.

We should update our existing Help icon to be a Font Awesome icon in SVG w/PNG fall-back.

The JS code of the modal should capture tab inside the modal.

Documents, not resumes, should include their document type in the details one a distinct line after the title.

I defined the section head in the typography because it was a good candidate for a universal element. However, I need design team review.

On both desktop and in iOS our 768px breakpoint is not working.

The U.S. Design Standards disabled button state is a little less disabled than we'd like. The issue has been raised:

uswds/uswds#944

We need to add a disabled button to our system to demonstrate the alteration I made to opacity.

This issues tracks creating and documenting the modals we have introduced in Application Guide: Welcome and Confirm Deletion.

While we have our success alert demonstrating that an alert is dismissible I failed to extend that to the other alerts (probably because the US Standards don't include the ability to dismiss an alert and we started from their code). We should make our alerts uniform and thus add the ability to dismiss them.

Quadrina and @raywilliams let me know that the default modal isn't working outside of the application guide because we have modals that have quite a bit of content. I'd prefer we didn't use modals in those situations, but we'll tackle that independently. For now, we need a wide variation that allows for scrolling inside of the modal.

I just noticed that the Standards define different header sizes for the Source Sans Pro headings and body pairing, which we are using. Those sizes are only defined in the styleguide.css file for the system itself and so I didn't notice them. Easy to fix but, we've got to communicate this immediately to the dev team.

cc/ @PeterToohey

This issue tracks creating variations of the JOA Summary component, initially for use in the application guide.

We've introduced a new secondary alert button that uses $color-secondary-darkest. Unfortunately, that leaves us with no darker color for the active state. We either need to lighten the default state and use darker for active or introduce a darker red for the active state.

When I created the disabled state of the Document/Thumbnail component I also removed the controls for viewing and deleting. This actually violates a use case whereby an agency may only select a Resume Builder resume and a user may have 5 handcraft resumes. Thus they would need to delete one in order to create a Resume Builder resume. We disable the non-Resume Builder resumes so that they are not selectable. However, they need to be viewable and deletable.

We need to create a consistent footer component that features global navigation.

• Update links to include the required links: http://www.digitalgov.gov/resources/required-web-content-and-links/
• Fix uneven columns between M and MLL breakpoints (without using an additional div which breaks the default JS; OR add our own JS)
• Fix hidden sub-sections below M breakpoint.
• Reconcile updated visual style from USDS v.8.
• Add FAQs to Help.
• Fix hierarchy in v2 (Documents & Profile are children of Home).
• Pick a variation to go with.

Somehow I removed the placeholder variation. Put it back.

This issue tracks creating the main navigation component.

We have several instances of the "Show More" pattern on the site. We should create a component for this and include a variation that drops the "Show Less” toggle. The design of the pattern that I'm most familiar with is that Show More simply opens to reveal more content and there is no toggle to close it. If there should be a toggle then the content might be better suited to an accordion.

Hey Matt,

Here are the Thumbnails and Alerts in PNG format. You can take a look at the PSD's here:

smb://wdcvfxsvs01/USAJOBS-GOVT/Program Management/Outreach, Communications and Usability/Outreach, Communications & Usability/Usability/Design/Application Guide/Style Guide

Let me know if you need anything else,
Kyhry.

• Default
• Hover
• Selected
• Focus
• Add
• Disabled
• Corrupt
• Incomplete
• Loading
• Placeholder

A few changes:

• Can the modal body copy have the same left padding/margin as the Modal Header so that everything is aligned?
• Can the cancel button be a link instead of an actual button as shown in the mockup?
• Can we change the color of the line dividers to a light grey or reduce the stroke so it's less heavy, as shown in the mockup?

The guidelines around the top level navigation are a little sparse.

• Accessibility guidelines (role=nav, aria-haspopup=true)
• Keyboard interactions (these need to be defined in JS first)
• Triggers (hover, tap, etc.)

This issue tracks the work on the second version of the global header.

• All header variations should have a bottom border.
• Switch to Min's updated visual style.
• Truncate the user's name
• Create variation with drop down menus.
• Add icons inside of labels.
• Auto-complete locations.
• Auto-complete recent searches.
• Disclaimer background should stretch to the end of the viewport though the content should max out at $site-max-width.

We've introduced a new secondary start (green) button to start the application wizard. The default color is $color-green-dark (#2d8700), a new color we've introduced. The hover state should be lighter. The next lightest color is $color-green, which meets the AA contrast level. However, it is not significantly lighter and thus the hover change isn't as apparent as it is on other buttons. We need to make the default darker so we can keep the hover state.

I haven't tried to do dev on the design system on Windows thus I'm not certain that our documentation is accurate for Windows users (which are dev team is).

This issue tracks creating and documenting the 2 alert styles we have introduced: 1 success and 1 warning variation.

We need to set a logical tabindex through the page:

http://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms
http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/H4

This tracks the work to create the progress indicator component for the responsive demo app guide page.

We've removed applying the grid to existing pages from our goal of applying the design system to the entire site. The grid will be applied to new components and pages as we go. Thus existing pages will retain Boostrap's grid. Thus this issue tracks the work to grab Bootstrap's grid scss file and include it in base so that both grid systems are present.

Bootstrap compability. Add this to the Layout section.

We need to design and create guidelines around a required field legend. We don't have guidance from the Standards as of yet on this and it will be in My Account as well as other sections of the site.

Tasks

• Define whether or not the legend is in fact required on every screen at every viewport
• Define location of the "Required" legend
• Define visual style of "Required" legend.

My sense is that the legend should be somewhere. There may be guidance in the 508 standards around this, but I couldn't locate them easily.

Safari and Chrome are driving me to distraction trying to vertically center the X within the circle. They can agree on how to display neither the line-height or height of that element. At this point it would save time to just have our own perfectly centered version of the icon in svg and png formats.

I want to provide greater clarity around form labels. Most of these are shown in the U.S. Design standards but are not explicitly called out:

• Use Required or Optional instead of red asterisk right aligned to the end of the form field and included in the label

Then there are some guidelines that are specific to our current implementation that will describe what to drop:

• No colon at the end of labels
• No icons inside of or attached to form inputs

To show this we might consider prototyping this complete page:
https://my.usajobs.gov/Support#Miscellaneous-Suggestions-to-Improve-USAJOBS

We've revised the design a bit to make it more clear when a user has reached the 5 resume limit. To do that we need a disabled state of the Add Resume button.

This issue tracks the work on the required documents side panel of application guide.

Somehow I broke the drawer handle for the code examples. The Documentation handle works fine.

The current modal design - or more specifically the usage of modals for full forms - allows users to accidentally lose work. Here is an user interaction I observed:

• Open modal (e.g. add work experience on application)
• Fill out most of form (e.g. approx. 10/14 fields)
• Accidentally click one pixel outside of modal, triggering close
• As a result, the modal is closed, and the data lost. The user then had to start over again and re-enter all of the data. (This actually happened 2-3 times in the course of one application.)

This could be fixed by:

• Not using modals for forms longer than a couple of fields
• Disabling the close by clicking outside the modal for forms
• Preserving the data, so that clicking on the add (e.g. add work experience) again would be populated with the partial data (may necessitate 'clear' buttons for form, etc.)

(Reference: MODAL - DEFAULT WITH FULL FORM from http://usajobs.github.io/design-system/modals/)

This task got closed out as a part of another issue, but it should have been broken out. Given that I used flexbox in _alert.scss I need to verify the .no-flexbox styles on at least IE9.