docs: improved Graphite templating docs

docs/sources/features/datasources/graphite.md

@@ -76,17 +76,35 @@ this consolidation is done using `avg` function. You can how Graphite consolidat
 > client side by Grafana. And depending on your consolidation function only one or two can be correct at the same time.
 
 ## Templating
-You can create a template variable in Grafana and have that variable filled with values from any Graphite metric exploration query.
-You can then use this variable in your Graphite queries, either as part of a metric path or as arguments to functions.
 
-For example a query like `prod.servers.*` will fill the variable with all possible
-values that exists in the wildcard position.
+Instead of hard-coding things like server, application and sensor name in you metric queries you can use variables in their place.
+Variables are shown as dropdown select boxes at the top of the dashboard. These dropdowns makes it easy to change the data
+being displayed in your dashboard.
+
+Checkout the [Templating]({{< relref "reference/templating.md" >}}) documentation for an introduction to the templating feature and the different
+types of template variables.
+
+### Query variables
+
+The query you specify in the query field should be a metric find type of query. For example a query like `prod.servers.*` will fill the
+variable with all possible values that exists in the wildcard position.
 
 You can also create nested variables that use other variables in their definition. For example
 `apps.$app.servers.*` uses the variable `$app` in its query definition.
 
+### Variable usage
+
+You can use a variable in a metric node path or as a parameter to a function.
 ![](/img/docs/v2/templated_variable_parameter.png)
 
+There are two syntaxes:
+
+- `$<varname>`  Example: apps.frontend.$server.requests.count
+- `[[varname]]` Example: apps.frontend.[[server]].requests.count
+
+Why two ways? The first syntax is easier to read and write but does not allow you to use a variable in the middle of word. Use
+the second syntax in expressions like  `my.server[[serverNumber]].count`.
+
 ## Annotations
 
 [Annotations]({{< relref "reference/annotations.md" >}}) allows you to overlay rich event information on top of graphs. You add annotation

docs/sources/reference/templating.md

@@ -12,8 +12,8 @@ weight = 1
 
 <img class="no-shadow" src="/img/docs/v4/templated_dash.png">
 
-Templating allows you to make your dashboards more interactive and dynamic. Instead of hard-coding things like server, application
-or sensor id in you metric queries you can use variables in their place. Variables are shown as dropdown select boxes at the top of
+Templating allows for more interactive and dynamic dashboards. Instead of hard-coding things like server, application
+and sensor name in you metric queries you can use variables in their place. Variables are shown as dropdown select boxes at the top of
 the dashboard. These dropdowns makes it easy to change the data being displayed in your dashboard.
 
 ## What is a variable?
@@ -29,7 +29,7 @@ Panel titles and metric queries can refer to variables using two different synta
 - `[[varname]]` Example: apps.frontend.[[server]].requests.count
 
 Why two ways? The first syntax is easier to read and write but does not allow you to use a variable in the middle of word. Use
-the second syntax for scenarios like this: `my.server[[serverNumber]].count`.
+the second syntax in expressions like  `my.server[[serverNumber]].count`.
 
 Before queries are sent to your data source the query is **interpolated**, meaning the variable is replaced with its current value. During
 interpolation the variable value might be **escaped** in order to conform to the syntax of the query language and where it is used.