diff --git a/docs/platform-engineers/addon/intro.md b/docs/platform-engineers/addon/intro.md
index 48cf44cc..83a32796 100644
--- a/docs/platform-engineers/addon/intro.md
+++ b/docs/platform-engineers/addon/intro.md
@@ -160,7 +160,7 @@ spec:
 
 The detail of the example is [velaux](https://github.com/kubevela/catalog/tree/master/addons/velaux).
 
-#### Define parameter for addon
+### Define parameter for addon
 
 When the resource is defined in CUE, you can also define parameters for addon by writing a `parameter.cue` file in the resources folder as shown below:
 
@@ -170,7 +170,7 @@ parameter: {
 }
 ```
 
-It can cooperate with the resource file in CUE:
+It can cooperate with the resource file in CUE, here we have a CUE file `vela-apiserver.cue` :
 
 ```cue
 output: {
@@ -200,6 +200,7 @@ kind: Application
 spec:
   components:
   - type: webservice
+    name: api-server
     properties:
     	image: "oamdev/vela-apiserver:v1.4.0"
     traits:
@@ -208,6 +209,8 @@ spec:
         name: my-account
 ```
 
+**Please notice** The **name** of component is the same with file name in the `resource/` folder with file type suffix trimmed.
+
 ##### Use context render component
 
 Besides using `parameter` to generate component dynamically, you can also use `context` to  render runtime variable.
diff --git a/docs/resources/helm-rollout-v1.jpg b/docs/resources/helm-rollout-v1.jpg
new file mode 100644
index 00000000..857f582d
Binary files /dev/null and b/docs/resources/helm-rollout-v1.jpg differ
diff --git a/docs/resources/helm-rollout-v2.jpg b/docs/resources/helm-rollout-v2.jpg
new file mode 100644
index 00000000..a8316e8f
Binary files /dev/null and b/docs/resources/helm-rollout-v2.jpg differ
diff --git a/docs/resources/object-rollout-v1.jpg b/docs/resources/object-rollout-v1.jpg
new file mode 100644
index 00000000..3e687689
Binary files /dev/null and b/docs/resources/object-rollout-v1.jpg differ
diff --git a/docs/resources/object-rollout-v2.jpg b/docs/resources/object-rollout-v2.jpg
new file mode 100644
index 00000000..81da386a
Binary files /dev/null and b/docs/resources/object-rollout-v2.jpg differ
diff --git a/docs/tutorials/helm-rollout.md b/docs/tutorials/helm-rollout.md
index 70706167..610a7eb9 100644
--- a/docs/tutorials/helm-rollout.md
+++ b/docs/tutorials/helm-rollout.md
@@ -80,6 +80,10 @@ Let's continue our demo, the first deployment has no difference with a normal de
 vela status canary-demo
 ```
 
+If you have enabled [velaux](../reference/addons/velaux) addon, you can view the application topology graph that all `v1` pods are ready now.
+
+![image](../resources/helm-rollout-v1.jpg)
+
 Access the gateway endpoint. You can see the result always is `Demo: V1`
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
@@ -142,6 +146,10 @@ After verify the success of the canary version through business-related metrics,
 vela workflow resume canary-demo
 ```
 
+View topology graph again, you will see `kruise-rollout` trait created a `v2` pod, and this pod will serve the canary traffic. Meanwhile, the pods of `v1` are still running and server non-canary traffic.
+
+![image](../resources/helm-rollout-v2.jpg)
+
 Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
 
 ```shell
diff --git a/docs/tutorials/k8s-object-rollout.md b/docs/tutorials/k8s-object-rollout.md
index bf19bc3c..74c11fa3 100644
--- a/docs/tutorials/k8s-object-rollout.md
+++ b/docs/tutorials/k8s-object-rollout.md
@@ -128,6 +128,10 @@ Let's continue our demo, the first deployment has no difference with a normal de
 vela status canary-demo
 ```
 
+If you have enabled [velaux](../reference/addons/velaux) addon, you can view the application topology graph that all `v1` pods are ready now.
+
+![image](../resources/object-rollout-v1.jpg)
+
 Access the gateway endpoint with the specific host.
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
@@ -260,6 +264,10 @@ Services:
 
 The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
 
+View topology graph again, you will see `kruise-rollout` trait created a `v2` pod, and this pod will serve the canary traffic. Meanwhile, the pods of `v1` are still running and server non-canary traffic.
+
+![image](../resources/object-rollout-v2.jpg)
+
 Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
 
 ```shell