As you plan your customizations, their scope will mean a lot. Do you want the changes to be seen across the UI, only in a particular community, or only in selected patches of the UI reached by certain URLs? The scope decision will be one of the first you make.
You'll use scope to map your custom themes to the UI so you can test your changes. Without this mapping, it won't be possible to really see how things are shaping up. The scope decisions are built on your design goals. If you're making more than just a few minor changes, you'll find it's useful to think in terms of UI boundaries. Will your changes impact certain kinds of content or certain communities, or certain content in certain communities? Your conceptual decision related to UI boundaries translates into implementation decisions about themes and their mappings.
In other words, group your change ideas into batches that correspond to the UI globally, or to communities, or to specific URLs. Then create custom themes corresponding to those groups, add custom templates to the themes, and map the themes to the UI scope you defined.
Jive applies custom templates using the following hierarchy in which more specific levels override broader ones. The precedence from specific to general is URL > Community > Global, as described here:
Make a theme the global theme when you want its templates to impact UI across the application. Keep in mind that if you separately customize those same templates in themes that are mapped to communities or URLs, those more specific mappings will take precedence.
Note that the word "global" is used in the path names for some templates. This can be a bit confusing. The name doesn't mean that the templates are always applied globally, but rather than they guide UI that's not specific to certain content types. A "global" template will be applied only to the parts of the UI its containing theme is mapped to, as described above.
Map a theme to a community for community-specific look and feel. Using custom templates for blogs, communities, or discussions, you can have those content look like they belong together in a particular community. "Global" custom templates will guide the look of their UI elements only in that community.
Keep in mind that if you separately customize those same templates in themes that are mapped to URLs, the more specific mappings will take precedence.
Mapping a theme to a URL is a great way to customize very specific parts of the UI, such as blogs or user profiles (or even just one person's blog and profile).
When specifying the URL to map to, you use regular expression syntax. For example, a dot (.) means "any character" and an asterisk ( * ) means "any number of characters."
For example, blog URLs follow this form:
<context_root>/blogs/<blog_name>/<post_year>/<post_month>/<post_date>/<post_title>
So the following would map a theme to "any blog posts from 2010":
.*/blogs/.*/2010.*
You can imagine how you might fill a theme with custom templates that guide blog appearance, along with some cross-content UI, then map that theme to this URL to call out content in blog years.
Here are a few more examples in which the instance root is merely "community":
All blogs
This reads as "any number of any characters followed by 'community/blogs' followed by any number of any characters."
.*community/blogs.*
// Or more universally:
.*blogs.*
Just the blogs main page
This reads as "any number of any characters followed by 'community/blogs' and nothing else."
.*community/blogs
// Or more universally:
.*blogs
A specific user's blog
This reads as "any number of any characters followed by 'community/blogs/gladys' and any number of any characters." In other words, this maps to all posts in Gladys' blog.
.*community/blogs/gladys.*
// Or more universally:
.*blogs/gladys.*