Merge branch 'main' of github.com:WestpacGEL/GEL-next into develop

.rsync-filter

@@ -0,0 +1,36 @@
+- node_modules
+- azure-pipelines.yml
+- .storybook
+- .changeset
+- .git
+- .dist
+- .github/workflows
+- .husky
+- .eslintrc.js
+- .gitattributes
+- .gitignore
+- .npmrc
+- .prettierignore
+- .prettierrc
+- **/__mocks__
+- **/.next
+- **/dist
+- **/coverage
+- **/icons
+- **/fonts
+- **/.swcrc
+- **/tsconfig.json
+- **/tsconfig.build.json
+- **/**.d.ts
+- **/**.css
+- **/**.zip
+- **/**.spec.*
+- **/**.styles.*
+- **/**.stories.*
+- **/*.md
+- **/*.svg
+- **/*.png
++ **/*.ts
++ **/*.tsx
++ **/*.js
++ **/*.jsx

apps/site/src/content/articles/journey-management.yaml

@@ -0,0 +1,22 @@
+name: Journey Management
+cardTitle: Journey Management
+description: >-
+  Customer journey management is the ongoing process of understanding customer
+  experiences, identifying opportunities, and optimising customer journeys. It
+  is key to creating improved customer experiences and driving strong business
+  outcomes.
+thumbnail:
+  src: https://res.cloudinary.com/westpac-gel/image/upload/journey_map_card.png
+  alt: image of 2 circles with an arrow between them.
+  height: 1212
+  width: 3168
+smallDescription: >-
+  Use storytelling to empathise with customers, articulate their pain points an
+  define meaningful solutions.
+image:
+  src: >-
+    https://res.cloudinary.com/westpac-gel/image/upload/v1714714884/journey-map-hero.png
+  height: 1289
+  width: 2400
+author: DX Journey Team
+publishedAt: 2024-05-01T10:40

apps/site/src/content/articles/journey-management/content.mdoc

@@ -0,0 +1,13 @@
+## Why we use Journey Management
+
+Successful customer journey management will result in increased customer satisfaction, plus stronger business outcomes, including increased revenue and repeat purchasing.
+
+In the Digital Experience Design team, we conduct research and analyse data to identify opportunities to improve our customer experiences across our product and service journeys.
+
+As building out great customer experiences is a team effort, we provide access to journey maps so that teams touching on a particular experience can help contribute to delivering the improvements we’ve identified and learn from other journeys that contain similar interactions.
+
+Each of our journey maps demonstrate the optimal end-to-end experience for a particular group of customers seeking to fulfil a need. You’ll find the experience broken down into stages they go through to complete a task, the channels they interact with, the pain points we seek to solve, and a recommended experience based on their needs and behaviours.
+
+This invaluable information aligns our teams, enabling everyone to help contribute to delivering better futures for our customers, bankers and brokers.
+
+[Access the Journey Maps in Confluence](https://confluence.srv.westpac.com.au/display/DXD/Journey+Map+Index)

apps/site/src/content/articles/the-grid.yaml

@@ -16,7 +16,10 @@ smallDescription: >-
   system.
 image:
   src: >-
-    https://res.cloudinary.com/westpac-gel/image/upload/v1663138770/cl819vrci000eam8id8qd2k5d.png
-  height: 1080
-  width: 1920
+    https://res.cloudinary.com/westpac-gel/image/upload/v1716958040/Breakpoints_xcjnof.png
+  alt: >-
+    Image showing the 6 breakpoints and where they are likely to be applied ie.
+    Phone, Tablet, Laptop etc.
+  height: 1070
+  width: 2718
 author: Justin Spencer

apps/site/src/content/articles/the-grid/content.mdoc

@@ -10,17 +10,18 @@ The first hurdle in responsive design is to accept that you never know the exact
 
 ## **Breakpoints**
 
-A ‘breakpoint’ is a predefined viewport width. The Design System utilises 5 breakpoints. At each breakpoint we have the option to make adjustments to the interface design or layout using CSS. For example, we can adjust how many columns an element should span, the size of the text, its colour, visibility etc.
+A ‘breakpoint’ is a predefined viewport width. The Design System utilises 6 breakpoints. At each breakpoint we have the option to make adjustments to the interface design or layout using CSS. For example, we can adjust how many columns an element should span, the size of the text, its colour, visibility etc.
 
 This is how we define each of the 5 breakpoints:
 
-- **XS** - The Extra Small breakpoint begins at 0px and goes to 575px. (Note: Our minimum supported viewport is 320px)
-- **XSL** - Commonly known as the Phablet this breakpoint, begins at 576px and goes to 767px
-- **SM** - The Small breakpoint begins at 768px and goes to 991px
-- **MD** - The Medium breakpoint begins at 992px and goes to 1199px
-- **LG** - The Large breakpoint begins at 1200px and keeps going (Note: We cap this width at 1224px by applying a max-width to the container).
+- **XS** - The Extra Small breakpoint begins at 0px and goes to 575px. (Note: Our minimum supported viewport width is 320px)
+- **XSL** - Commonly known as the Phablet this breakpoint, begins when the viewport reaches 576px and goes to 767px
+- **SM** - The Small breakpoint begins when the viewport reaches 768px and goes to 995px
+- **MD** - The Medium breakpoint begins when the viewport reaches 996px and goes to 1199px
+- **LG** - The Large breakpoint begins when the viewport reaches 1200px and goes to 1583px
+- **XL** - The Extra Large breakpoint begins when the viewport reaches 1584px (Note: At this point the grid width is fixed at 1440px wide).
 
-As shown in the graphic above it’s important to understand that a breakpoint indicates a range value. For example, if you set an element to span 12 columns in XS view this will remain the case while the viewport is between 0px and 575px wide. Once the viewport has reached the XSL breakpoint you now have the option to change how many columns your element spans (amongst other things).
+As shown in the graphic above it’s important to understand that a breakpoint indicates a range value. For example, if you set an element to span 12 columns in XS view this will remain the case while the viewport is between 0px and 575px wide. Once the viewport has reached the XSL breakpoint you have the option to change how many columns your element spans (amongst other things).
 
 ## **Columns**
 

apps/site/src/content/design-system/accessibility/design-system-accessibility/design/inclusive-content-writing/content.mdoc

@@ -1,3 +1,6 @@
-As well as offering simple products, we need to ensure we communicate their specifics in a clear and inclusive way. Complicated terminology can be appropriate for a certain audience, especially when talking about products and services that are specific to customers in more specialised fields. But in general our products and services are for the whole community, so we should ensure that content is easily readable, and if there are situations where that is not possible then we need to use supplemental content to clarify it. According to WCAG ‘Supplemental content is required when text demands reading ability more advanced than the lower secondary education level—that is, more than nine years of school.’
+Writing in a clear, simple way promotes equal access to information, creating a society where no one is left behind.  As a guide, our content needs to be understood by a 13 year old to cater for people who have a basic understanding of legal and financial language and who use English as a second language, as well as those with an intellectual or learning disability. Some common things to consider when writing for a diverse audience include:
 
-The most common form of supplemental content in a digital context would be the ‘Help text’ you find associated with forms and calculators.
+- spelling [acronyms](/content/guidelines/acronym) in full when they’re first mentioned.
+- writing [link copy that provides context](/content/guidelines/hyperlinks-email-addresses) instead of using ‘click here’.
+- [avoid using terms that assumes the way a person interacts with something](/content/guidelines/calls-to-action-ctas), for example, ‘walk’, ‘simply’, ‘see’ or ‘watch’.
+  For more information on writing simply and inclusively, check out the [Writing for Digital Guidelines](/content/writing-for-digital).

apps/site/src/content/design-system/accessibility/design-system-accessibility/design/principles-of-accessibility/content.mdoc

@@ -1,21 +1,21 @@
 The following comes from the [W3.org](https://www.w3.org/) website, it explains the four principles of accessibility that the Web Contact Accessibility Guidelines (WCAG) and Success Criteria are organised around:
 
-> _**1\. Perceivable**_ _- Information and user interface components must be presentable to users in ways they can perceive._
->
-> _This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)_
->
-> _**2\. Operable**_ _- User interface components and navigation must be operable._
->
-> _This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)_
->
-> _**3\. Understandable**_ _\- Information and the operation of user interface must be understandable._
->
-> _This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)_
->
-> _**4\. Robust**_ _- Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies._
->
-> _This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)_
->
-> _If any of these are not true, users with disabilities will not be able to use the Web._
+> ***1. Perceivable*** *- Information and user interface components must be presentable to users in ways they can perceive.*
+> 
+> *This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)*
+> 
+> ***2. Operable*** *- User interface components and navigation must be operable.*
+> 
+> *This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)*
+> 
+> ***3. Understandable*** *- Information and the operation of user interface must be understandable.*
+> 
+> *This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)*
+> 
+> ***4. Robust*** *- Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.*
+> 
+> *This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)*
+> 
+> *If any of these are not true, users with disabilities will not be able to use the Web.*
 
 See [www.w3.org/WAI/WCAG21/Understanding/intro](https://www.w3.org/WAI/WCAG21/Understanding/intro) for the entire article.

apps/site/src/content/design-system/accessibility/design-system-accessibility/index.yaml

@@ -4,23 +4,34 @@ description: >-
   be diligent and aware of the impacts the decisions we make have at all stages
   of product delivery. The following areas need to be considered when designing
   for accessibility and inclusion.
+namedExport:
+  discriminant: false
+excludeFromNavbar: false
 design:
   - title:
       name: Principles of accessibility
       slug: principles-of-accessibility
+    noTitle: false
   - title:
       name: Inclusive product design
       slug: inclusive-product-design
+    noTitle: false
   - title:
       name: Inclusive content writing
       slug: inclusive-content-writing
+    noTitle: false
   - title:
       name: Accessible interfaces
       slug: accessible-interfaces
+    noTitle: false
   - title:
       name: Accessibility testing
       slug: accessibility-testing
+    noTitle: false
   - title:
       name: Deprecated components
       slug: deprecated-components
+    noTitle: false
 accessibility: []
+relatedComponents: []
+code: []

apps/site/src/content/design-system/components/footer/code/development-examples/content.mdoc

@@ -0,0 +1,24 @@
+### Basic footer
+
+```jsx
+<>
+  <Footer
+    brand="wbc"
+    hideLogo
+  >
+    <div>
+      <SecurityIcon
+        className="float-left shrink-0 max-md:mr-1 md:mr-2"
+        color="muted"
+        size={{
+          initial: 'small',
+          md: 'medium'
+        }}
+      />
+      <p className="text-muted">
+        Footer content
+      </p>
+    </div>
+  </Footer>
+</>
+```

apps/site/src/content/design-system/components/footer/design/footer/content.mdoc

@@ -1,4 +1,4 @@
-sdfsdf
+This is the basic footer component, the content should be project specific.
 
 ```jsx
 <>
@@ -16,7 +16,14 @@ sdfsdf
         }}
       />
       <p className="text-muted">
-        Footer content.
+        Our site and your transactions are secure. You can read our{' '}
+        <Link
+          href="#"
+          type="inline"
+        >
+          security information
+        </Link>
+        . © 2023 Westpac Banking Corporation ABN 33 007 457 141 AFSL and Australian credit licence 233714.
       </p>
     </div>
   </Footer>

apps/site/src/content/design-system/components/footer/index.yaml

@@ -29,4 +29,8 @@ relatedComponents:
     slug: /foundation/icons
   - title: Headers
     slug: /components/header
-code: []
+code:
+  - title:
+      name: Development examples
+      slug: development-examples
+    noTitle: false