-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Epic] Populate manual content #247
Comments
The 'Purpose' section PR was created and an initial temp file was added. Content is now being added. Each purpose section has 2 parts - a one liner highlighted at the top of the doc and an explanatory paragraph that can expand on this in a little more detail. Each purpose is being copied to the .md file and committed before being rephrased to improve the grammar correctness and clarity etc. and commited again to the PR above. This way we can review original vs proposed. Goals used for rephrasing: Audience - knowledgeable, Formality - neutral, Domain - general, Intent - inform. |
All purposes have been added to the initial temp file and rephrased accordingly, attempting to retain consistency in format across each. PR for review please: #273 |
Following review and feedback this morning:
|
Following our team's conversation this morning it was decided that it was not necessary to repeat the component names in the 'purpose' one-liners (which will be assumed to reside in the component js and be pulled into the docs to automate). PR for review please: #273 |
Updated purpose text to not refer to 'We use...' to retain correct focus. |
I've started adding the index pages and adding the updated purposes as discussed earlier today with Mekala, I've just worked on ns-a... so far and amended what was already there or added new ones based on the example set of pages Drew created. Note that on ns-article, I have included that standard deprecation message we mentioned. I've added it to the top of all of that component's pages as it would need to be clear on all pages if the user hadn't arrived via the Overview page etc. I think I'll flesh out this "ns-a..." category with all the content in the right places for now before rinse and repeat for the others. I have also noticed we have Purpose/Types on the Overview page, we also have Types under Guidance on the default structure ticket #245 but I will assess as I go in case that feels like duplication... |
Added ns-tabs overview and example and amalgamated ns-tab into it. Branch feature/tab-into-tabs - this will negate the need for a separate ns-tab page as that component is never used in isolation. We will be looking to do similar with ns-timeline and ns-timeline-event. |
Creating component HTML files for docs snippets "_examples" based on Storybook. Agreed approach is to name each file as its type. The default is standard.html, others may have appendages conjoined with underscores, eg. direct_link.html and direct_button.html. Accordion to CTA done so far and saved locally for inclusion once Drew has completed work on his branch affecting the file structure. Point to note: The ns-cta has many types and an example of each that shows loading, or within form etc. My thoughts were that perhaps that could be a configuration option? Eg. a checkbox for 'Loading state' etc? (similar to how we used 'knobs' or 'controls' in storybook?) |
All HTML _examples for general components (accordion to video) have been created and saved locally (as above). Form components _examples now in progress. |
All HTML _examples for form components (appointment-picker to selector) have been created and saved locally (as above). deprecated and nsx experiences _examples now in progress. |
HTML _examples for deprecated and nsx experiences have been created and saved locally. |
Observation: Some snippet examples use British Gas type content, others in Lorem Ipsum. The components are visually British Gas style and these particular set of docs I understand are for British Gas. So I am anticipating a similar but nuanced set for any other brand that may adopt Nucleus, rather than a one-size-fits-all, vanilla Nucleus set of docs. Question: It could be better if we make it all consistent, but which way? Having content relevant to the business using it might illustrate the example usage well, but is it taken too literally, and just copied without changes being considered? Using a random irrelevant topic for content has also been shown to confuse. And using Lorem Ipsum may seem too vague. What is the consensus on this? |
Outcome
Each component has all the manual content required for a full doc
Scope
Sections to be completed for all components.
Overview
Guidance
Implementation
(This approach has changed from completing each component individually. Following the discussion on 6 December it was agreed we can proceed with creating 1 file of content with all components covered for each section to allow work on the technical aspect to proceed in parallel until ready to unite).
The text was updated successfully, but these errors were encountered: