Skip to content
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

Closed
11 tasks done
Tracked by #243
PtitBen opened this issue Nov 6, 2023 · 12 comments
Closed
11 tasks done
Tracked by #243

[Epic] Populate manual content #247

PtitBen opened this issue Nov 6, 2023 · 12 comments
Labels
Epic Epic ticket Type: Documentation Improvements or additions to documentation

Comments

@PtitBen
Copy link
Contributor

PtitBen commented Nov 6, 2023

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).

@PtitBen PtitBen mentioned this issue Nov 6, 2023
26 tasks
@PtitBen PtitBen changed the title Populate manual content Populate manual content for each component Nov 6, 2023
@PtitBen PtitBen changed the title Populate manual content for each component Populate manual content Nov 6, 2023
@PtitBen PtitBen added the Type: Documentation Improvements or additions to documentation label Nov 6, 2023
@PtitBen PtitBen added this to the Internal tools milestone Nov 6, 2023
@RobTobias123 RobTobias123 self-assigned this Dec 6, 2023
@RobTobias123
Copy link
Contributor

RobTobias123 commented Dec 6, 2023

The 'Purpose' section PR was created and an initial temp file was added. Content is now being added.
#273

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.

@RobTobias123
Copy link
Contributor

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

@RobTobias123
Copy link
Contributor

Following review and feedback this morning:

  • Component names in purposes follow the same simpler, clearer convention of 'Use ns-xyz to...' instead of 'Use the XYZ component to...'
  • All component names in purpose are displayed using back-ticks
  • An example of the automated deprecation message as a Starlight 'caution aside' also contains an example of the back-ticked display of the component name with link. (Is this too specific?)
  • Image references removed (image/examples will be part of the overview, not purpose section)
  • Parsed corrected to passed
  • Checked the contrast ratio of the back-tick text-background and text and it appears it needs changing in the custom.css as not quite enough contrast (light mode) for the size (needs to be 4.5:1):

Image

Image

@RobTobias123
Copy link
Contributor

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

@RobTobias123
Copy link
Contributor

Updated purpose text to not refer to 'We use...' to retain correct focus.
Reworded ns-alert secondary paragraph to be more generic and consistent with others.
Adjusted and checked custom.css colour values for light and dark to ensure 'Deprecated' pill and back-ticked names meet contrast ratio requirements.

@RobTobias123
Copy link
Contributor

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...

@RobTobias123
Copy link
Contributor

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.

@RobTobias123
Copy link
Contributor

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?)

@RobTobias123
Copy link
Contributor

All HTML _examples for general components (accordion to video) have been created and saved locally (as above). Form components _examples now in progress.

@RobTobias123
Copy link
Contributor

All HTML _examples for form components (appointment-picker to selector) have been created and saved locally (as above).
I have marked a couple as I have some questions that I will compile for addressing in the next docs catch up (tomorrow).

deprecated and nsx experiences _examples now in progress.

@RobTobias123
Copy link
Contributor

HTML _examples for deprecated and nsx experiences have been created and saved locally.

@RobTobias123
Copy link
Contributor

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?

@RobTobias123 RobTobias123 added the Epic Epic ticket label Jan 5, 2024
@RobTobias123 RobTobias123 changed the title Populate manual content [Epic] Populate manual content Jan 5, 2024
@RobTobias123 RobTobias123 added Status: On Hold Awaiting for clarification or another issue to be resolved and removed Status: On Hold Awaiting for clarification or another issue to be resolved labels Jan 29, 2024
@RobTobias123 RobTobias123 removed their assignment Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic Epic ticket Type: Documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants