removed colon in headings

content/BCPatterns/facade-pattern/index.md

@@ -14,11 +14,11 @@ The intent of this pattern is to provide a unified API to a single or a collecti
 - Testability
 - Maintainability
 
-## Context: 
+## Context
 
 Whenever you want to write an isolated piece of business logic, from now on referred to as subsystem, this pattern should be applicable.
 
-## Problem: 
+## Problem
 
 The facade pattern addresses two main problems:
 - Over time as systems grow, they tend to become complex and harder to comprehend. By adding a facade on top of the subsystem, that complexity is hidden, and a clear API is defined.
@@ -133,10 +133,10 @@ codeunit 3970 "Image Impl."
 
 There are no rules for the subsystem, except that access needs to be **internal**. How you implement, how much you document, how you test, is entirely up to you and not the business of the outside caller. Of course, you should apply all of the best practices and patterns anyway, as you and possibly other developers will have to understand, extend and maintain the subsystem too. But from the view of this pattern, the complexity of the subsystem is irrelevant - just as long as it's not accessible.
 
-## Usage: 
+## Usage
 The facade pattern is one of the most prominent patterns in the [system application](https://github.com/microsoft/ALAppExtensions/tree/main/Modules/System). You will find plenty of examples here.
 
-## Benefits:
+## Benefits
 
 The benefits of this rather simple pattern should be abundantly clear by now. But let's go over them once more, structured by the advantages this patterns brings:
 

content/BCPatterns/generic-method-pattern/index.md

@@ -14,11 +14,11 @@ The goal of this pattern is to facilitate a lot of things in one single awesome
 - Testability
 - Encapsulation
 
-## Context: 
+## Context
 
 Whenever you have to write an isolated piece of business logic, this pattern should be applicable.
 
-## Problem: 
+## Problem
 
 Usually, when you ask people where to place code, they all have their own opinion: on a table or page, or in some kind of codeunit library where lots of functions will be placed, or .. .  In fact, does it matter?  It sure does, because in many cases, the code simply isn't maintainable, let alone extendable or testable.
 
@@ -253,12 +253,12 @@ You might have noticed that the naming of our method is quite strict:
 
 It is important to align these namings.  It indicates that the codeunit only does one thing (remember: encapsulation), and it improves searchability from outside the codeunit (for example when you're searching symbols or something).
 
-## Usage: 
+## Usage
 Currently, there is no usage of this pattern in the BaseApp.  
 
 The pattern has a main advantage in an ISV product, just because of the decoupling and extensibility.  Although, I have seen many occasions where parts of the pattern was useful on PTE's as well.  You simply never know if ever at the customer site, there is going to be another partner that needs to create its own PTE, and has to depend on yours.  So I'd say, this pattern is everywhere applicable, no matter the type of the app.
 
-## Benefits:
+## Benefits
 
 As I said, it will facilitate a lot of advantages.  Let's explain a bit more in depth: