A big part of your portal design is its navigation. You want navigation to be
consistent in approach and instrumental in providing a successful user
experience. Additionally, it should be easy to create, easy to standardize, and
easy to apply to multiple locations.
OracleAS Portal fulfills all of these requirements by offering you
key tools and objects for streamlining the creation and deployment of site-wide,
as well as page-specific, navigation. Key tools and objects include templates,
navigation pages, categories and perspectives, custom searches, and
navigation-related items, such as Smart Links, Smart Text, and Page Paths.
This technical note demonstrates a variety of navigation models and provides
information on how to construct them. It does not walk you step-by-step through
the process, however. If you'd like that information, you'll find everything you
need in the Oracle Portal online help.
Before we get into the specifics of creating navigation pages, it will be
useful to understand the difference between navigation pages and navigation item
types.
Navigation pages
Navigation pages are special pages you create under the Navigation Pages node
in the Portal Navigator.
They are exempt from searches, and consequently are not included in search
result sets. Like regular pages, they can be published as portlets and reused
throughout your portal. The navigation pages you publish as portlets are
automatically added to the list of navigation pages that are made available
during page and page template creation. For example, once you create a
navigation page, you can select it from the Navigation Page For Banner
field of the Create Page and Create Page Template wizard, or you can add the
navigation page as a portlet directly to a page or a page template.
Navigation items
When you first create a navigation page, it's blank. You create navigation on
it by adding different types of items. Among these, the most likely will be
navigation type items. Navigation items are elements that enable you to create
navigation in your portal. OracleAS Portal provides you with a set of
built-in navigation item types that save you a lot of hand-coding. These include
smart links, smart text, lists of objects, page paths, and so on. With most of
these types, you merely make a single selection, and Portal assembles the URL
and other link information automatically.
Navigation pages can contain all types of items, not just navigation type
items. And navigation type items can be placed in item regions on any type of
page, not just navigation pages.
To create our examples, we planned a page group devoted to a company's Human
Resources department. We created a main Human Resources page, and at the same
level, an Images and a Content page. For Human Resources, we created three
subpages devoted respectively to Services, Policies, and Benefits. We broke
Policies down further with Time Reporting, Compensation, and Confidentiality
subpages.
For our page group, we also devised a simple classification system, with
categories for services, policies, and benefits, and perspectives for
executives, managers, and individual contributors.
Our plan was to offer several kinds of navigation:
A horizontal navigation bar
A vertical navigation bar
A linked page path
A page group map
A drop-down list of all pages in our site
Pick lists for categories and perspectives
Subpage links
Tabs for main content classifications (Services, Policies, Benefits)
Note: For your own page groups, it's not likely that you'll provide
this many navigation options for your pages. They're included here to provide
a look at how these are accomplished and what they can look
like.
First we created a blank template and called it Human Resources
Template. We did this first because the only time you can apply a template
to a page is when you create the page. One advantage of using a template is that
when you make changes to the template, all pages that use the template update
with the changes automatically, sparing you having to update each page
individually. Another is that it gives you complete, consistent, standard
control over the appearance of your pages.
A limitation to consider is that the layout (regions and tabs) of any page
that uses the template is limited to whatever the template offers. So, if you
want to place tabs on a page that is based on a template, you must add the tabs
to the template, rather than to the individual page. This means that all pages
that use the template will also display those tabs.
In consideration of these advantages and limitations, we decided to base only
our main page (Human Resources) on the template. For other pages, we planned to
place navigation elements as needed, retaining the flexibility we required to
control the layout of each page.
We created our page group (Navigation Examples) and then a hierarchy of pages
beneath it. In the Page Creation Wizard, we selected <None> for
Navigation Page For Banner because our navigation pages weren't created
yet. At the first subpage level (under our root page Navigation Examples)
we created the Human Resources page, making sure to select Human
Resources Template when given the opportunity. Then we created the other pages
and series of subpages described in the previous section. For these, we did not
select a template.
We created the Images page for use as a central storage place for all
images we planned to use in our page group. On the Images page, we changed the
default region to an item region, and uploaded all the images we planned to use
in our page group. This simplified the reuse of images. When we wanted to use an
image elsewhere in the page group, we'd right-click it on the Images page,
select Properties from the resulting menu, and in the Properties window,
copy the name Portal assigned to the uploaded image.
To use this most efficiently, we often had two browser windows open: one for
our working page; the other for grabbing image names and navigating to target
pages to copy their URLs.
We created the Content page for use as a central storage place for all our
content--articles, documents, and all other types of content deliverables. Our
plan was to have one page where all content contributors would go to upload
their content. Content contributors would be required to select a relevant
category to classify the type of information they were providing. We planned to
construct custom search portlets on our subpages that each looked for a
particular category, for example services, policies, or benefits, and placed
search results on a targeted page.
For example, on the Services subpage, we planned to place a custom search
portlet that ran each time the page was accessed. It would search for all
content classified under the services category, then place the search
results on the Services subpage.
Under our page group's Navigation node, we created a few navigation pages:
one for the horizontal navigation bar, one for the vertical navigation bar, and
one for the Page Path navigation item type. (We created a page path navigation
page to allow for one-time configuration--that is, we set it up once for our
navigation page, rather than many times for each page we planned to place it
on.) When we created the horizontal and vertical navigation bar pages, we turned
on item-level security to allow for hiding sensitive navigation items from
unauthorized users and groups.
We planned to publish these pages as portlets after we had completed creating
all of them. By waiting to publish, we prevented them from being exposed to
other users accessing the Portlet Repository.
Note: For specifics on how to perform any of these tasks, see the
OracleAS Portal online help.
There is more than one way to create a navigation bar: you can create a Text
item, then hand code the entire thing in the text item's rich text editor
(before you start, be sure to check the View HTML source check box in the
rich text editor); you can also use Portal Smart Links, a combination of Smart
Links and Text item types, or page link items.
We chose the URL item type. It significantly reduced the amount of hand
coding, and ensured all links in the navigation bar aligned uniformly. (When we
tried a combination of Smart Links and Text items, the alignment varied slightly
according to type. We didn't try page link items, though they also provide a
method for rapidly assembling links to other pages.)
After we created our navigation page, we edited its properties to enable item
level security (you'll find this control on the Access tab in the
navigation page properties). We put this in place to give ourselves the option
of hiding individual items (links) from unauthorized users or groups of
users.
To get the items to align horizontally, we created a four-column item region.
Our images included labels, so when we created our URL item, we didn't give it a
display name. Otherwise, this name would have appeared redundantly beneath its
associated image. To sharpen right alignment, we moved the items closer together
by adding two regions to the left. We added our company logo to the leftmost
region. We added it as a URL item type, creating a link from the logo to our
home page. We didn't include a display name with this item, because the graphic
contained all the information we wanted.
This was our result in View Page mode:
Once completed, we went back into Navigation Page Properties, and on the
Optional tab, checked the Publish As Portlet check box. This placed the
navigation page into the Portlet Repository, where we could select it later for
placement on a template or regular page.
We used a similar technique to create the vertical navigation bar. This time,
we created a one-column item region so that our items lined up vertically, one
under another. We also turned on item-level security for this page. Again we
worked in two browser windows: one for adding our URL items; the other for
getting Portal-assigned image names and browsing to target pages for URL
information.
Once we completed the vertical navigation bar, we went to the Optional
tab of Navigation Page Properties and checked the Publish As Portlet
check box.
Including a linked page path
While our navigation bars provided a way of moving deeper into our site, we
also wanted to provide an easy way for users to know their current location and
to move back up the page hierarchy. To do this, we created another navigation
page and added the Page Path navigation item type to it. We set the number of
levels to display at two. This causes the page path to display the current
location plus no more than two levels up the page hierarchy.
We published this page as a portlet, and temporarily placed it on the deepest
level of our page hierarchy to see its effect. In the following illustration,
you'll see that the page toolbar path lists the entire path, while our Page Path
item list only the current location plus two levels up. We kept the default
separator (:).
In the Portlet Repository, the navigation page portlet was located under
New > Navigation Examples. Before we placed the path portlet, we
edited the region we planned to use, turning off portlet headers and borders,
thinking them unnecessary in this circumstance.
We debated using an Object Map Link built-in navigation item type in addition
to our image-based vertical navigation bar. Clicking this link opens a page that
lists and links to all pages in the portal to which the current user has
access.
We created an image for our link and uploaded it to our images page. Then we
went to the navigation page that hosts the vertical navigation bar, and added
the Object Map Link to it (in our illustration, it's the last link on the page).
We used our uploaded graphic and did not enter a display name. In lieu of
specifying item level security, we specified that the link should inherit the
access privileges associated with its host page.
In Graphical Layout view, we clicked the link to view the object map.
We were logged in to Portal as a user with view access to everything;
consequently, our Object Map showed links to all pages available in this Portal
instance. It became clear that the Object Map Link was not as focussed on our
Human Resources pages as we wanted it to be. In this circumstance, we were
concerned that it might be confusing to our target audience. We removed it from
our example, but kept it in mind for later use with sites more generally
focussed on the entire enterprise.
We satisfied our desire for a quick pick list of our specific group of pages
by using the List of Objects built-in navigation item type. When you build this
type of item, you can select specific pages as well as categories and
perspectives for inclusion on the list. When users select a page, they're taken
to the specific page. When they select a category or perspective, they're taken
to a dynamically generated page that lists and links to all items and objects
classified under that category or perspective.
You also have the option of several list formats: a drop-down list, a list of
links, or a list of links/images. The links/images option displays either the
display name of the page, category, or perspective, or the image you have
associated with the page, category, or perspective. (You associate an image with
a page, category, or perspective via the Optional tab on the page, category, or
perspective's associated Properties page.) When you specify links/images, images
always take precedence; but if you have not associated an image with a page,
category, or perspective, the object's display name is used instead.
Adding a list of pages
We decided to add a drop-down list of all Human Resources-related pages just
below the vertical navigation bar. We particularly liked the List of Objects
item because it gave us a very specific level of control over what pages
appeared on the list. We had so few pages, that we chose to include all relevant
pages on the list. If our site were large, we would likely have chosen top level
pages for the list, then included deeper levels of navigation on the pages
themselves.
We split horizontally the item region that hosts the vertical navigation bar,
then added the List of Objects item to the lower region. In the Add Item wizard,
we selected all relevant Human Resources pages and rearranged them into their
hierarchical order. We specified the display name Locate a Specific
Page.
Once we placed the list, we felt the need for more space between the list and
the preceding vertical navigation elements. To get this, we added an empty
region between the two.
We chose a link format for the categories and perspectives lists. We used the
display name to provide a very brief description: Locate by Type, for
categories; Locate by Intended Audience, for perspectives.
As we determined with our selection of pages, there were so few categories
and perspectives on these lists that it made sense to display all of them. If
the lists of categories and perspectives were long, we might have limited those
we wished to display, or selected a drop-down list format for our list of
objects.
Once we developed the navigation elements we wanted on our main page (Human
Resources), we added them to the blank template on which we based the Human
Resources page: the Human Resources Template. When we completed each
navigation page, we edited their properties, going to the Optional tab to
check the Publish As Portlet check box. This made our navigation pages
available to us as portlets in the Portlet Repository under New >
Navigation Examples.
Note: Notice that Portal used the name of our page group (New
> Navigation Examples) for the folder structure it created in the
repository. It automatically created this hierarchy in the repository when we
published our first navigation page as a portlet.
Then we edited our template. First, we edited the region properties to turn
off the region headers and borders. We added the horizontal navigation (with the
company logo) and the page path navigation to our template. Then we created
three tabs: Services, Policies, and Benefits. Each of these tabs in turn had its
own portlet region. In these, we intended to add page portlets. This is
explained in more detail in the next section.
Evaluating the visual effect of our first attempt, we decided the page path
should be centered on the page rather than left-aligned. To revise it, we went
back to the original navigation page that hosts the page path and edited region
properties to center region content. (You make these kinds of adjustments on the
original page, rather than in the page portlet, where you have no control over
the internal layout of portlet content.)
Once added to the template, all navigation elements automatically appeared on
our Human Resources page.
Creating navigation through custom searches and subpage
links
Now we wanted to start dealing with our deeper subpage levels. Our intention
was to display content on each subpage via a custom search portlet. Then we
intended to publish each of the subpages as portlets and place them on our main
(Human Resources) page. (This is the content that would populate the three tabs
we created in our template.)
We decided to place our vertical navigation bar on each of these subpages. We
could just as easily have placed it on each of the tabs on our main page or we
could have placed it in a dedicated region on our main page, with the tab
regions pushed to the right of the page. Our decision here was partly practical
but largely aesthetic. For practical purposes, we wanted our subpages to have
their own navigation; if we had it there as well as on the main page, we would
have had redundancy--navigation on our main page, and on the subpages published
as portlets (on the main page). Aesthetically, we wanted the tabs to extend
across the entire page.
Starting with the Services subpage, we created two side-by-side portlet
regions: the left one for vertical navigation, the right one for the custom
search portlet. For both of these, we turned off portlet headers and borders. We
placed the vertical navigation page portlet, then the custom search portlet.
Then we customized our search.
Creating a custom search
On our Services subpage, we toggled to the Layout view of Edit mode. Next to
our custom search portlet, we clicked the Edit Defaults link. We clicked
the Advanced button, to create an advanced search, then changed the name
of our search to Search Services. We specified that we wanted to limit
our search to a selected page group, and selected Navigation Examples
(our page group's name) from the Available Page Groups list.
We deselected all check boxes that gave users any selection or submission
options. We specified only Category as our selected attribute. When given
the opportunity to specify a default value for Category, we selected
Services. We checked the Auto Query check box to ensure that this
search would run each time this portlet was displayed (no need to enter a search
criteria in the subsequent field).
On the last customization page under Search Results Display, we selected the
radio button next to This Search Portlet. This meant our results would
display automatically wherever this custom search portlet was placed--in our
case, on the Services subpage. We selected Items as our Search Results
Type, and selected the attributes we wanted to display with each returned item:
Display Name or Image, Description, and Create Date--with blank lines between
each and two after the last one to create sufficient space between search
results.
We chose the same style for our search results portlet as we were using on
our page (a slightly altered Mandarine), and cleared all the Search Result
Options check boxes. We kept the default of 20 hits per page.
We clicked Finish, and took a look at our page. (Anticipating this
moment, we had earlier loaded a number of documents classified under
services.)
When the page is invoked, the search is automatically submitted and the
results displayed. Once we were satisfied with our result, we went into the
Optional tab of Page Properties and published this page as a portlet.
We used this process with the Benefits page, as well as with the Policies
page, with slight variation. The Policies page had additional subpages: Time
Reporting, Compensation, and Confidentiality. On the Policies page, we created
an additional region above the one that hosted the custom search portlet. We
converted it to an item region and added a Subpage Display item. This built-in
navigation type lists and links to the next one or two (you specify) levels of
subpages beneath the current page.
To create visual separation between the subpage links and the custom search
portlet, we edited the custom search portlet's region properties to display
portlet headers and borders. Then we examined our result.
Bookmark
