Adding Design Manual content guidelines, corresponding updates to footer

[stephanieosan]

Additions

• Design manual structure page
• General content guidelines page
• For page components section page

These content guidelines pages aren't included in the top nav, instead we've redesigned the footer to include a link to them there.

Changes

• Reorganized/added links in footer based on audience (For visitors, For contributors)
• Removed the paragraph disclaiming that our standards might not yet be reflected on cf.gov (they are now!!)
• Moved over the Open Source info to the far-right of the footer

Future considerations

• There will be more content guidelines pages added soon-ish (One for guidelines on brand pages is coming soon. Eventually we'll get pages for global elements and data viz.)
• It might be nice to add link/s to our Design Manual github wiki in the "For contributors" section of the footer that cover the process for suggesting new standards/modules entirely.

Review

• One of the following for content: @kurzn @ielerol @sonnakim
• And a front end dev to make sure I didn't ruin everything mucking around in the footer? @Scotchester ? Someone else?

Check out changes here: https://stephanieosan.github.io/design-manual/content-guidelines/content-guidelines.html

[ielerol]

Looking pretty good! I do have some notes on the content:

• On the main page, I think we should take out the sentence saying page components are generally atomic design atoms. For one, I think a lot of them are molecules, but also, right now we're not really addressing atomic design approaches at all in the design manual content, so that sentence seems really out of place. At some point we may want to reconsider the design manual content more generally in terms of an atomic design perspective, but for now I think we should leave out stray references to it.
• Right now the dynamic content info is duplicated in the general content guidelines section and the page components section. It's only in page components because it didn't have a better home before we created the more general section. I suggest taking it out of that page, and just including a reference under "style" to dynamic content. Something like "Styles should be as detailed as necessary to create the component, including things like font, color, padding, etc. If dynamic content has been defined for a property such as color, use the appropriate data file or include file to reference the property." And maybe link to the wiki instructions on using data files?

[sonnakim]

Looks good to me too! Just a couple comments:

1. Under "General content guidelines >> Formatting content"— in the first paragraph, maybe we encourage presenting a visual example where relevant next to that bulleted list of components? (Side note: the bulleted example on the github.io page isn't bulleting 😭 )

Formatting content

Present components of behavior, styling, use cases, etc as bullet points, to allow readers to skim content easily. Include an image or a live code example of those components as needed.

Example:

2. Under "General content guidelines >> Formatting content" —perhaps we should rewrite the first sentence to explain what's meant by "dynamic content" and "content 'snippets'"? Like, make clear up front that we're talking about a shortcut for content writers to pull standardized data (like our color palettes) into design manual pages without having to write things out.

3. Under "page components", we repeat the "language" and "dynamic content" sections that appear in General content guidelines. Should we take them out of one of the sections? Or do we want to leave as is?

[stephanieosan]

I am making all of your suggested changes @ielerol and @sonnakim! The only one I was a little confused by/unsure about was your (2) Sonna. I'm totally down to change stuff if you think we should clarify more, but I'm not doing a good job of following which part I should change. Could you screenshot + provide a recommended sentence/words to add?

Thank you!!

[stephanieosan]

Who has the power to do a final review and merge on this?

[Scotchester]

Looks good from a front-end POV 👍

[Scotchester]

Oops... spoke too soon. You need to make these changes to the widths in the Less code, lest they be overwritten the next time someone recompiles the Less.

That code currently defines things in terms of grid columns.

Let me know if you need further assistance with updating those.

[sonnakim]

@stephanieosan Okay, here's what I've got! Please replace the highlighted sentence below:

with the bolded words here:

Use dynamic content, or shortcut references to data used site-wide, to simplify the process of documenting standards. Rather than writing out the hex number for a brand palette color, you could use a dynamic content reference to automatically pull that hex number into your design manual page. This eliminates the need to copy and paste the same content again and again or to update many separate pages if standards change over time.

[jimmynotjim]

@stephanieosan Could you make the content changes and I'll look into helping with the less changes. Looks like we could easily get this merged.

[jimmynotjim]

Less fix is ready for review => stephanieosan#1

[jimmynotjim]

@stephanieosan just wanted to bump the content change @sonnakim suggested. If you don't think you'll get to it I can try to find time today.