Update table format

Author: tiffany jernigan

content/guides/app-enhancements-label-design.md

@@ -95,7 +95,7 @@ perform these queries: `=`, `==`, and `!=`.
 | =        | equal to or is |
 | ==       | equal to or is |
 | !=       | not equal to or is not |
-{{< table />}}
+{{< /table >}}
 #### Label Query Examples
 
 Find all components in Kubernetes that are related to running MySQL
@@ -136,7 +136,7 @@ include:
 | component | The component within the architecture | database |
 | part-of | The name of a parent application this application is part of | wordpress |
 | managed-by | The tool being used to manage the operation of an application | app-manager |
-{{< table />}}
+{{< /table >}}
 
 VMware recommends you extend the above labels with the following, where relevant.
 
@@ -151,4 +151,4 @@ VMware recommends you extend the above labels with the following, where relevant
 | repository | A URL to the repository that contains this application's source code | "github.com/kubernetes/kubernetes" |
 | managed-by | The tool being used to manage the operation of an application | helm |
 | business-unit | The business unit who owns this application | "finance" |
-{{< table />}}
+{{< /table >}}

content/learningpaths/application-development/cloud-native-development.md

@@ -69,7 +69,7 @@ Cloud native concepts are numerous. The following ones are the most common. They
 | Cloud Native Patterns | A catalog of reusable solutions to recurring problems occurring in cloud native applications. Each pattern describes an architectural problem, its solution, and implied benefits, and drawbacks. |
 | Domain-Driven Design | A software development philosophy that encourages thinking in business domains at each step of the process: discovery, architecture, and design. [Domain-Driven Design (DDD)](https://github.com/ddd-crew/welcome-to-ddd) comprises a variety of practices (for example, Event Storming) and concepts (for example, Bounded Context), while infusing a common "ubiquitous" language for better collaboration and alignment between business people and software engineers. DDD is not an all-or-nothing deal. You can apply the ideas from DDD as much or as little as you feel is beneficial to the project you're working on. |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 ### Application life-cycle {id=sw-life-cycle}
 
@@ -79,7 +79,7 @@ Cloud native concepts are numerous. The following ones are the most common. They
 | DevOps | A collaborative mindset consolidating practices, cultural philosophies, tools, and patterns designed to break down the organizational barriers between development and operations departments along application life-cycles. Breaking down silos empower organizations to:<br/><br/><ul><li>Deliver new features faster and more often in production.</li><li>Have a more reliable operating environment.</li><li>Improve communication and collaboration.</li></ul>With an initial focus on software developers and operation engineers, DevOps has quickly evolved to include other departments and functions: security (DevSecOps), finance (FinOps), network (NetOps), and business.
 | CI/CD | Combines the practices of continuous integration and either continuous delivery or continuous deployment. CI/CD bridges the gaps between development and operation activities and teams by enforcing automation in building, testing and deployment of applications. These automated and connected steps are often referred to as a (CI/CD) pipeline. |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 
 ### Supporting infrastructure {id=support-infra}
@@ -93,7 +93,7 @@ Cloud native concepts are numerous. The following ones are the most common. They
 | Immutable infrastructure | An infrastructure paradigm in which servers are never modified after being deployed. If something needs to be changed, updated, or fixed, new servers built automatically with the appropriate changes are provisioned to replace the old ones. In a traditional mutable server infrastructure, servers are continually updated and modified in place. |
 | * as a Service | Infrastructure (IaaS), Container (CaaS), Platform (PaaS), Function (FaaS) or Software (SaaS) as a service are categories of cloud computing services. They provide APIs to manage on-demand life-cycles of the corresponding abstraction layers: virtualized infrastructures, containers, application platforms, functions or external software. |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 
 ### Team culture {id=culture}
@@ -109,7 +109,7 @@ Cloud native concepts are numerous. The following ones are the most common. They
 | Growth mindset | Embraces learning while strengthening beliefs that you can control and improve abilities. It envisions challenges and failure as opportunities to grow personally and values constructive feedback. Especially in IT, where change is the only constant, perpetual learning is a growth mantra. |
 | Learning organizations | A company that facilitates the learning of its members and continuously transforms itself. The core benefits offered by being a learning organization is a competitive advantage. |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 
 ## Identify the twelve factors of cloud native applications {id=factors}

content/learningpaths/consulting-around-design-systems/is-a-design-system-right-for-your-team.md

@@ -82,7 +82,7 @@ Fully adopting an existing open-source system and staying largely (or entirely)
 | Usually include some ability to customize colors and fonts. | Sheer number of options can create challenges in consistency (especially for portfolios). |
 | Good systems have invested in accessibility and browser compatibility, which you will get for free. | Tethered to the maintainers of the system—no input in direction. |
 | You get bug fixes and updates for free. | Difficult decision to walk back from. |
- {{< table />}}
+ {{< /table >}}
 
 #### Adapting a System  
 
@@ -96,7 +96,7 @@ Starting with an open-source system as a foundation, but building custom transla
 | Provides a <em>little</em> more customization and differentiation than straight adopting. | Higher cost than adopting a system. |
 | Lower-cost than a custom system. | Adds a translation layer to build, learn and maintain. |
 | | Requires <em>some</em> resources to manage and maintain (maybe not dedicated). |
- {{< table />}}
+ {{< /table >}}
 
 #### Creating a System  
 
@@ -113,7 +113,7 @@ Taking the DIY option and creating a custom system entirely from scratch. From c
 | Full control over choices, processes, direction and maintenance. | <strong>High cost (possibly <em>extremely </em>high).</strong> |
 | | Requires creation of documentation. and training materials. |
 | | Difficult decision to walk back from. |
- {{< table />}}
+ {{< /table >}}
 
 #### Skipping a system (or growing one slowly)
 
@@ -129,7 +129,7 @@ Taking the option to skip a design system entirely or to let one evolve from an
 | Provides a way to test components that might later become a system | Risky (can be short-sighted) |
 | Benefit of customization without cost of a dedicated team | Risky (can be short-sighted) |
 | Can be speedy | Difficult decision to walk back from |
- {{< table />}}
+ {{< /table >}}
 
 > This is worth repeating: **not everyone needs a design system**. With their current surging popularity, this can be a difficult idea to sell. If you think a design system might not be the right choice, consider starting with something lightweight like a style guide paired with a basic process for sharing reusable patterns, and then pulling the design system lever when (and if) you’re confident that you’ve hit the value-add tipping point.
 

content/practices/user-research-introduction-session/dos-and-donts.md

@@ -41,7 +41,7 @@ Starting with easy topics will help people get relaxed, comfortable, and talking
 | ---- | ---- |
 | Tell me a little bit about what you do? | You answered that you hate __ in our recruiting survey. Why do you hate ___ ? |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Ask open-ended questions with “What”, “How” and “Why”.
 ##### Don’t ask leading questions or lead users through tasks.
@@ -57,7 +57,7 @@ The goal is to hear people speak in their own words as much as possible. It’s
 | Why did you do that? |  |
 | How did you do that? |  |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Seek concrete stories, past actions & behaviors.
 ##### Don’t seek generalizations or ask about future behavior.
@@ -72,7 +72,7 @@ The goal is to understand what happened in their past to give us clues about why
 | What do you think about this product? | Would you pay for this? |
 | Tell me about the last time you had a painful experience with this product. | What do you want? |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Give people time to answer the question.
 ##### Don’t fill in silence with more questions.
@@ -84,7 +84,7 @@ The goal is to give people space to think because being interviewed is difficult
 | ---- | ---- |
 | _Silence_ | Interrupting while interviewee is speaking |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Nod and say less. The interviewee is always right.
 ##### Don’t correct or contradict a research participant if they do something "wrong".
@@ -96,7 +96,7 @@ The goal is to get people speaking as honestly as possible and to encourage them
 | ---- | ---- |
 | User: This part doesn’t make sense. Is it supposed to do that?<br><br>Interviewer: What do you think it should do?<br><br>User: I think it would swap out all the pictures.<br><br>Interviewer: There is no actual answer here, we want to learn about what you expect. Thanks! | User: This part doesn’t make sense. Is it supposed to do that?<br><br>Interviewer: Oh, it's a slideshow and it's just broken in the prototype. You’re supposed to tap on the arrow and the next image should enter the page.<br><br>User: Oh I didn’t see that, sorry. |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Actively listen and dig deeper with “why” questions.
 ##### Don’t ignore users when they are struggling in silence, or they show surprise. 
@@ -109,7 +109,7 @@ The goal is to pay attention to the user as they are speaking and feel comfortab
 | ---- | ---- |
 | Interviewer: What do you think this page does?<br><br> User: Oh! I like that. Anyway, I think this page tells me my sleep duration.<br><br> Interviewer: Let’s rewind for a second, what did you mean by “Oh! I like that.”? | Interviewer: What do you think this page does?<br><br> User: Oh! I like that. Anyway, I think this page tells me my sleep duration.<br><br> Interviewer: Great, what would you do next? |
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Stay neutral about the product you are showing.
 ##### Don’t talk about or sell your product.
@@ -121,7 +121,7 @@ The goal with research is to have as unbiased feedback as possible. For example,
 | ---- | ---- |
 | Interviewer: We’re interested in having you test drive an idea that's related to sleep cycles. | Interviewer: We’re working on this mobile app that gives you an easy way to look at how much sleep you’re getting at night. | 
 |  |  |
-{{< table />}}
+{{< /table >}}
 
 #### Do: Wrap up with broad questions.
 ##### Don’t wrap up without having interviewees reflect on their experience.
@@ -132,7 +132,7 @@ Interviewees will have more to say. You can capture many interesting insights du
 | ---- | ---- |
 | How was this experience for you? Is there anything else pertaining to sleep that you’ve been thinking about lately? | We’ve got no more questions for you. Thanks, bye! |
 |  |  |
- {{< table />}}
+ {{< /table >}}
 
 ### INTERVIEW PRACTICE SILENT QUIZ
 Here are 3 “bad” questions. Turn them into good questions.