theartcher · Oct 29, 2025 · Oct 29, 2025 · Oct 29, 2025 · Oct 29, 2025 · Oct 29, 2025
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
@@ -22,6 +22,7 @@ jobs:
 
       - name: Install dependencies
         run: npm install
+
       - name: Build website
         run: npm run build
 

diff --git a/.github/workflows/test-deploy.yml b/.github/workflows/test-deploy.yml
@@ -20,5 +20,6 @@ jobs:
 
       - name: Install dependencies
         run: npm install
+
       - name: Test build website
         run: npm run build
diff --git a/README.md b/README.md
@@ -16,6 +16,7 @@ Each page follows a basic structure to ensure that a user can easily find metada
 
 1. The name of the design pattern.
    1. Include extra used names or alternative names used just below the title itself.
+   2. Each page needs a 'description' in the config, with a funny quote or otherwise short hook to get users engaged.
 2. The group the design pattern belongs to.
    1. Creational, Structural or Behavioral
 3. Description

diff --git a/docs/behavioral/_category_.yml b/docs/behavioral/_category_.yml
@@ -0,0 +1,11 @@
+label: Behavioral
+link:
+  type: generated-index
+  title: Behavioral Design Patterns
+  description: >
+    Behavioral are focussed on communication, the assignment of responsibilities between objects and complex transactions such as algorithms.
+  slug: /behavioral
+  keywords:
+    - design pattern
+    - behavioral
+    - software architecture
diff --git a/docs/Behavioural/chain-of-responsibility.mdx → docs/behavioral/chain-of-responsibility.mdx b/docs/Behavioural/chain-of-responsibility.mdx → docs/behavioral/chain-of-responsibility.mdx
diff --git a/docs/Behavioural/command.mdx → docs/behavioral/command.mdx b/docs/Behavioural/command.mdx → docs/behavioral/command.mdx
diff --git a/docs/Behavioural/iterator.mdx → docs/behavioral/iterator.mdx b/docs/Behavioural/iterator.mdx → docs/behavioral/iterator.mdx
diff --git a/docs/Behavioural/mediator.mdx → docs/behavioral/mediator.mdx b/docs/Behavioural/mediator.mdx → docs/behavioral/mediator.mdx
diff --git a/docs/Behavioural/memento.mdx → docs/behavioral/memento.mdx b/docs/Behavioural/memento.mdx → docs/behavioral/memento.mdx
diff --git a/docs/Behavioural/observer.mdx → docs/behavioral/observer.mdx b/docs/Behavioural/observer.mdx → docs/behavioral/observer.mdx
diff --git a/docs/Behavioural/state.mdx → docs/behavioral/state.mdx b/docs/Behavioural/state.mdx → docs/behavioral/state.mdx
diff --git a/docs/Behavioural/strategy.mdx → docs/behavioral/strategy.mdx b/docs/Behavioural/strategy.mdx → docs/behavioral/strategy.mdx
diff --git a/docs/Behavioural/template-method.mdx → docs/behavioral/template-method.mdx b/docs/Behavioural/template-method.mdx → docs/behavioral/template-method.mdx
diff --git a/docs/Behavioural/visitor.mdx → docs/behavioral/visitor.mdx b/docs/Behavioural/visitor.mdx → docs/behavioral/visitor.mdx
diff --git a/docs/creational/_category_.yml b/docs/creational/_category_.yml
@@ -0,0 +1,15 @@
+label: Creational
+link:
+  type: generated-index
+  title: Creational Design Patterns
+  description: >
+    Creational design patterns are all about class instantiation or object
+    creation. These patterns can be further divided into class-creation patterns
+    and object-creational patterns. While class-creation patterns use inheritance
+    effectively in the instantiation process, object-creation patterns use
+    delegation to get the job done.
+  slug: /creational
+  keywords:
+    - design pattern
+    - creational
+    - software architecture
diff --git a/docs/Creational/abstract-factory.mdx → docs/creational/abstract-factory.mdx b/docs/Creational/abstract-factory.mdx → docs/creational/abstract-factory.mdx
diff --git a/docs/Creational/builder.mdx → docs/creational/builder.mdx b/docs/Creational/builder.mdx → docs/creational/builder.mdx
@@ -1,6 +1,8 @@
 ---
 title: Builder
 hide_title: true
+description: >
+  Can we build? Yes we can! Do we need a Director? Maybe..?
 ---
 
 import { CreationalPatternTag } from "@site/src/components/pattern-page-features/pattern-alias-and-tag";
@@ -411,9 +413,9 @@ function BuilderDemo() {
 ```
 
 ## 🔗Relations to other patterns
-- The Builder pattern is often used in conjunction with the [Factory Method](/docs/Creational/factory-method) pattern, where the factory method creates a builder instance.
-- You can combine [Builder](/docs/Creational/builder) with [Bridge](/docs/Structural/bridge): the director class plays the role of the abstraction, while different builders act as implementations.
-- [Abstract Factories](/docs/Creational/abstract-factory), [Builders](/docs/Creational/builder), and [Prototype](/docs/Creational/prototype) can be implemented as [Singleton](/docs/Creational/singleton).
+- The Builder pattern is often used in conjunction with the [Factory Method](/docs/creational/factory-method) pattern, where the factory method creates a builder instance.
+- You can combine [Builder](/docs/creational/builder) with [Bridge](/docs/structural/bridge): the director class plays the role of the abstraction, while different builders act as implementations.
+- [Abstract Factories](/docs/creational/abstract-factory), [Builders](/docs/creational/builder), and [Prototype](/docs/creational/prototype) can be implemented as [Singleton](/docs/creational/singleton).
 
 ---
 

diff --git a/docs/Creational/factory-method.mdx → docs/creational/factory-method.mdx b/docs/Creational/factory-method.mdx → docs/creational/factory-method.mdx
diff --git a/docs/Creational/prototype.mdx → docs/creational/prototype.mdx b/docs/Creational/prototype.mdx → docs/creational/prototype.mdx
@@ -1,6 +1,8 @@
 ---
 title: Prototype
 hide_title: true
+description: >
+  Double the copies, double the fun.
 ---
 
 import { CreationalPatternTag } from "@site/src/components/pattern-page-features/pattern-alias-and-tag";
@@ -198,10 +200,10 @@ function PrototypeDemo() {
 ```
 
 ## 🔗Relations to other patterns
-- Designs that make heavy use of [Composite](/docs/Structural/composite.mdx) and [Decorator](/docs/Structural/decorator.mdx) can often benefit from using [Prototype](/docs/Creational/prototype). Applying the pattern lets you clone complex structures instead of re-constructing them from scratch.
-- [Prototypes](/docs/Creational/prototype) can help when you need to save copies of [Commands](/docs/Behavioural/command.mdx) into history.
-- [Abstract Factories](/docs/Creational/abstract-factory) classes are often based on a set of [Factory Methods](/docs/Creational/factory-method.mdx), but you can also use [Prototype](/docs/Creational/prototype) to compose the methods on these classes.
-- [Abstract Factories](/docs/Creational/abstract-factory), [Builders](/docs/Creational/builder), and [Prototypes](/docs/Creational/prototype) can be implemented as [Singleton](/docs/Creational/singleton).
+- Designs that make heavy use of [Composite](/docs/structural/composite.mdx) and [Decorator](/docs/structural/decorator.mdx) can often benefit from using [Prototype](/docs/creational/prototype). Applying the pattern lets you clone complex structures instead of re-constructing them from scratch.
+- [Prototypes](/docs/creational/prototype) can help when you need to save copies of [Commands](/docs/behavioral/command.mdx) into history.
+- [Abstract Factories](/docs/creational/abstract-factory) classes are often based on a set of [Factory Methods](/docs/creational/factory-method.mdx), but you can also use [Prototype](/docs/creational/prototype) to compose the methods on these classes.
+- [Abstract Factories](/docs/creational/abstract-factory), [Builders](/docs/creational/builder), and [Prototypes](/docs/creational/prototype) can be implemented as [Singleton](/docs/creational/singleton).
 
 ---
 

diff --git a/docs/Creational/singleton.mdx → docs/creational/singleton.mdx b/docs/Creational/singleton.mdx → docs/creational/singleton.mdx
@@ -1,6 +1,8 @@
 ---
 title: Singleton
 hide_title: true
+description: >
+  Just like God, there is only one.
 ---
 
 import { CreationalPatternTag } from "@site/src/components/pattern-page-features/pattern-alias-and-tag";
@@ -196,9 +198,9 @@ function SingletonDemo() {
 ```
 
 ## 🔗Relations to other patterns
-- [Factory Method](../Creational/factory-method.mdx), [Abstract Factory](../Creational/abstract-factory.mdx), or [Builder](../Creational/builder.mdx) may rely on Singleton to ensure a single configuration or product source is used globally.
-- [Facade](../Structural/facade.mdx) objects can themselves be singletons that encapsulate a subsystem behind a single interface.
-- Unlike [Flyweight](../Structural/flyweight.mdx), which manages many shared objects, Singleton restricts creation to precisely one object.
+- [Factory Method](/docs/creational/factory-method.mdx), [Abstract Factory](/docs/creational/abstract-factory.mdx), or [Builder](/docs/creational/builder.mdx) may rely on Singleton to ensure a single configuration or product source is used globally.
+- [Facade](/docs/structural/facade.mdx) objects can themselves be singletons that encapsulate a subsystem behind a single interface.
+- Unlike [Flyweight](/docs/structural/flyweight.mdx), which manages many shared objects, Singleton restricts creation to precisely one object.
 
 ---
 

diff --git a/docs/intro.md b/docs/intro.md
diff --git a/docs/overview.md b/docs/overview.md
@@ -0,0 +1,37 @@
+---
+title: Overview
+sidebar_position: 1
+---
+
+# Welcome to DesignPatternPedia
+
+Ever come across a piece of code and thought, “Why is this written like a Sudoku puzzle?” Congratulations, you’ve found a design pattern (assuming it's not some DIY project...).
+
+This site is your map to the collection of reusable solutions that help developers build reliable and maintainable software across different contexts and technologies.
+
+## So… what even is this?
+
+This documentation is a structured reference for software design patterns — recurring approaches to solving frequently encountered problems in software architecture and object-oriented design.
+
+Each pattern here summarizes a proven solution, the problem it addresses, and the trade-offs involved in applying it.  
+Understanding these patterns helps you write code that is consistent, maintainable, and adaptable to change.
+
+## For who is this?
+
+It is primarily aimed at (junior) software developers, but anyone is welcome to take a look! The documents can get a bit technical at times, so a bit of programming background is strongly recommended in order to not get completely lost.
+
+## How does it work?
+
+Patterns are grouped into three core categories, each describing a different perspective on how code can be organized and behave:
+
+- **Creational Patterns** – Deal with object creation and instantiation logic, aiming for flexibility and control over how objects are constructed. [Explore Creational Patterns ›](/docs/creational)
+
+- **Structural Patterns** – Focus on how classes and objects are composed to form larger structures while maintaining efficiency and scalability. [Explore Structural Patterns ›](/docs/structural)
+
+- **Behavioral Patterns** – Describe how objects interact and communicate, defining responsibilities and coordination in software systems. [Explore Behavioral Patterns ›](/docs/behavioral)
+
+Each core group then has it's own pattern page, which describes various aspects of the pattern itself. Subjects such as when to apply it, what it means, a metaphor to really connect it to reality and so forth. Pick a page and start reading from top to bottom.
+
+## Why does this exist?
+
+Software development often faces the same challenges — managing complexity, reducing coupling, and maintaining flexibility. Design patterns offer shared language and principles that developers can rely on to design systems that are easier to extend and understand. The existing website all lack a certain flavour, some are too complex and detailed, some simply do not contain enough precision. I hope to create an overarching experience which actually focusses on helping (junior) developers learn design patterns.
diff --git a/docs/structural/_category_.yml b/docs/structural/_category_.yml
@@ -0,0 +1,11 @@
+label: Structural
+link:
+  type: generated-index
+  title: Structural Design Patterns
+  description: >
+    Structural design patterns are concerned with how classes and objects are composed to form larger structures.
+  slug: /structural
+  keywords:
+    - design pattern
+    - structural
+    - software architecture
diff --git a/docs/Structural/adapter.mdx → docs/structural/adapter.mdx b/docs/Structural/adapter.mdx → docs/structural/adapter.mdx
diff --git a/docs/Structural/bridge.mdx → docs/structural/bridge.mdx b/docs/Structural/bridge.mdx → docs/structural/bridge.mdx
diff --git a/docs/Structural/composite.mdx → docs/structural/composite.mdx b/docs/Structural/composite.mdx → docs/structural/composite.mdx
diff --git a/docs/Structural/decorator.mdx → docs/structural/decorator.mdx b/docs/Structural/decorator.mdx → docs/structural/decorator.mdx
diff --git a/docs/Structural/facade.mdx → docs/structural/facade.mdx b/docs/Structural/facade.mdx → docs/structural/facade.mdx
diff --git a/docs/Structural/flyweight.mdx → docs/structural/flyweight.mdx b/docs/Structural/flyweight.mdx → docs/structural/flyweight.mdx
diff --git a/docs/Structural/proxy.mdx → docs/structural/proxy.mdx b/docs/Structural/proxy.mdx → docs/structural/proxy.mdx
diff --git a/docs/template.mdx b/docs/template.mdx
@@ -95,7 +95,7 @@ This sample is to get a 'feel' for the pattern. The code itself may not reflect
 ```
 
 ## 🔗Relations to other patterns
-- [Another pattern](./Creational/singleton.mdx) wiki link here
+- Another pattern wiki link here
 ---
 
 ## 📚Sources

diff --git a/docusaurus.config.ts b/docusaurus.config.ts
@@ -60,11 +60,26 @@ const config: Config = {
       },
       items: [
         {
-          type: "docSidebar",
-          sidebarId: "tutorialSidebar",
           position: "left",
-          label: "Patterns",
+          to: "/docs/overview",
+          label: "Overview",
         },
+        {
+          position: "left",
+          to: "docs/behavioral",
+          label: "Behavioral",
+        },
+        {
+          position: "left",
+          to: "docs/creational",
+          label: "Creational",
+        },
+        {
+          position: "left",
+          to: "docs/structural",
+          label: "Structural",
+        },
+        { to: "/manifest", label: "Manifesto", position: "left" },
         {
           href: "https://github.com/S7-OpenLearning-Individual/DesignPatternPedia",
           label: "GitHub",
@@ -76,16 +91,7 @@ const config: Config = {
       style: "dark",
       links: [
         {
-          title: "Docs",
-          items: [
-            {
-              label: "Tutorial",
-              to: "/docs/intro",
-            },
-          ],
-        },
-        {
-          title: "More",
+          title: "Contribute & Feedback",
           items: [
             {
               label: "GitHub",

diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
@@ -23,7 +23,8 @@
     "clsx": "^2.0.0",
     "prism-react-renderer": "^2.3.0",
     "react": "^19.0.0",
-    "react-dom": "^19.0.0"
+    "react-dom": "^19.0.0",
+    "swiper": "^12.0.3"
   },
   "devDependencies": {
     "@docusaurus/module-type-aliases": "3.9.2",

diff --git a/sidebars.ts b/sidebars.ts
@@ -1,4 +1,4 @@
-import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
+import type { SidebarsConfig } from "@docusaurus/plugin-content-docs";
 
 // This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
 
@@ -13,21 +13,7 @@ import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
  Create as many sidebars as you want.
  */
 const sidebars: SidebarsConfig = {
-  // By default, Docusaurus generates a sidebar from the docs folder structure
-  tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
-
-  // But you can create a sidebar manually
-  /*
-  tutorialSidebar: [
-    'intro',
-    'hello',
-    {
-      type: 'category',
-      label: 'Tutorial',
-      items: ['tutorial-basics/create-a-document'],
-    },
-  ],
-   */
+  sidebar: [{ type: "autogenerated", dirName: "." }],
 };
 
 export default sidebars;