edits

README.md

@@ -14,14 +14,6 @@ The WKT UI provides a graphical user interface that wraps the WKT tools, Docker,
 a Linux container image to use to run the domain, and setting up and deploying the software and configuration
 necessary to deploy and access the domain in your Kubernetes cluster.
 
-## Get Started
-
-Download the latest WebLogic Kubernetes Toolkit UI (WKT UI) application installers from the [Github Releases section](https://github.com/oracle/weblogic-toolkit-ui/releases) of this repository.
-Simply run the appropriate installer for your operating system.
-
-
-Initial launch of the application displays a thorough "Introduction" to the WKT UI. Step through
-it or dismiss it; you can peruse it at any time using `Help > Show Introduction`.
 
 ## About the Documentation
 

documentation/1.0/content/navigate/kubernetes/k8s-ingress-controller.md

@@ -19,7 +19,7 @@ description: "Install and configure an ingress controller."
 ### Ingress Controller
 This section supports two distinct functions related to an ingress controller. First, it supports installing an ingress
 controller to a Kubernetes cluster. Second, it supports adding the necessary routes to an ingress controller to make
-a deployed WebLogic domain's end-points accessible.
+a deployed WebLogic domain's endpoints accessible.
 
 #### Design View
 `Design View` helps you specify the data needed to install an ingress controller, if desired, and

documentation/1.0/content/navigate/kubernetes/k8s-weblogic-domain.md

@@ -203,7 +203,7 @@ the script itself. This change is left as an exercise for you because different
 existing standards for securely handling such credentials.
 
 ### Prepare Model
-`Prepare Model` is the same as was previously described in the [`Model`](model.md#prepare-model) section. It is only
+`Prepare Model` is the same as was previously described in the [`Model`]({{< relref "/navigate/model#prepare-model" >}})  section. It is only
 surfaced here because the `Clusters` pane of the `Design View` is populated only when `Prepare Model` is run.
 
 ### Deploy Domain

documentation/1.0/content/navigate/kubernetes/k8s-wko.md

@@ -84,7 +84,7 @@ the desired namespace selection strategy from one of the supported values:
  by this operator.
 - `Dedicated` - Only the Kubernetes namespace where the operator is installed will be managed by this operator.
 
-_Note that the operator Helm chart default is `List` but the application overrides this to specify `Label Selector` as
+_**Note** that the operator Helm chart default is `List` but the application overrides this to specify `Label Selector` as
 the default value._
 
 Each namespace selection strategy takes different input values; the form fields will change based on the strategy

documentation/1.0/content/navigate/model.md

@@ -153,13 +153,13 @@ For more information, see the WDT [model tokens](https://oracle.github.io/weblog
 documentation.
 
 In replacing credential values, `Prepare Model` must handle the replacement differently for the "Domain in Image" and
-"Model in Image" [domain locations]({{< relref "/navigate/project-settings#choosing-a-domain-location" >}}).
+"Model in Image" [domain locations]({{< relref "/navigate/project-settings#choosing-a-domain-location" >}}):
 
-With "Domain in Image", the WebLogic Image Tool creates the domain while creating the image. As such, it has no
+- With "Domain in Image", the WebLogic Image Tool creates the domain while creating the image. As such, it has no
 knowledge of Kubernetes so the token replacement uses variable tokens so that domain creation has access to the actual
 credential values. You must ensure that all variables have valid values prior to running `Create Image`.
 
-For "Model in Image", the domain is created at runtime by the WebLogic Kubernetes Operator running in a Kubernetes
+- For "Model in Image", the domain is created at runtime by the WebLogic Kubernetes Operator running in a Kubernetes
 cluster. As such, token replacement uses secret tokens for all credential fields. You must to be sure to provide
 values for all secret reference fields using the `WebLogic Domain` section's `Secrets` pane so that the required secrets
 get populated correctly during domain deployment. For more information, see [WebLogic Domain]({{< relref "/navigate/kubernetes/k8s-weblogic-domain.md" >}}).

documentation/1.0/content/navigate/project-settings.md

@@ -16,7 +16,7 @@ input for the project on:
 
 #### Choosing a Credential Storage Scheme
 The WKT UI application can securely store credentials for your project or not store them at all. The three choices
-are to:
+are:
 
 - Use the Native OS Credential Store
 - Store Encrypted Credentials in the WKT Project File
@@ -59,23 +59,23 @@ project.
 #### Choosing a Domain Location
 When getting started with a new WKT Project, one of the first things to consider is where you want the domain to reside.
 Domains can reside in a container, in an image, or in a persistent volume. Your choice will expose and hide different
-fields across most sections of the UI. The following describe the implications of the three locations.
+fields across most sections of the UI. The following describe the implications of the three locations:
 
-`Created in the container from the model in the image` - The newest and most popular location for a domain is in the container. This is known as "Model in Image" but also
+- `Created in the container from the model in the image` - The newest and most popular location for a domain is in the container. This is known as "Model in Image" but also
 referred to as a "From Model" in the underlying WKT tooling. In this case, the set of model-related files are added to
 the image. When the WebLogic Kubernetes Operator domain object is deployed, its inspector process runs and creates the
 WebLogic Server domain inside a running container on-the-fly. While this process adds a small amount of overhead at
 startup, it also makes it easier to maintain the image. For example, you can have a common WebLogic Server image that
 is updated periodically to pick up the latest Patch Set Updates (PSUs). Then, you use that image to add the
 most recent version of the WebLogic Deploy Tooling and your domain model files as a layer on top.
 
-`Created as part of the image` - This selection stores the domain in the image. This is known as "Domain in Image" but also is referred to as "Image"
+- `Created as part of the image` - This selection stores the domain in the image. This is known as "Domain in Image" but also is referred to as "Image"
 in the WebLogic Kubernetes Operator configuration. Using this option, the domain is created from the model by the
 WebLogic Image Tool (using the WebLogic Deploy Tooling) and baked into the image. While this saves a little overhead
 at startup, it is more expensive to maintain due to the need to recreate the domain every time a new WebLogic
 Server image is created.
 
-`Externally created in a Kubernetes persistent volume` - This selection stores the domain in a Kubernetes persistent volume; this is known as "Domain in PV".
+- `Externally created in a Kubernetes persistent volume` - This selection stores the domain in a Kubernetes persistent volume; this is known as "Domain in PV".
 This closely approximates the traditional way of maintaining a domain where the domain is created on disk and then
 used and maintained for as long as necessary. Depending on which Fusion Middleware products you are using, this may be
 your only supported choice for running the domain in Kubernetes. The WKT UI application currently doesn't do anything to help
@@ -101,6 +101,6 @@ installation directories.
 
 #### Choosing the Image Build Tool
 To build new images, inspect images, and interact with image repositories, the WKT UI application uses an image build
-tool, which defaults to `docker`. The image build tool must be installed locally, as mentioned in the [Prerequisites](site/prerequisites.md).
+tool, which defaults to `docker`. The image build tool must be installed locally, as mentioned in the [Prerequisites]({{< relref "/setup/prerequisites.md" >}}).
 While `docker` is currently the most popular tool, many vendors (for example, Oracle, IBM RedHat, Google) are moving to
 use `podman` by default.