A KNOWLEDGE TREE USING QUEST WEB PARTS

1.

We use Quest Web Parts on the company Intranet which has more than 7000 users. In a previous entry in
the Build Better SharePoint Contest I showed a document navigation system, where categories are used to
establish a simple menu system. This works well as long as the categories are relatively few and do not
have too many items. For a more diverse structure with a lot of items and categories and sub-categories a
more tree-like system is called for. For this the Quest menu web parts are very well suited, and by using the
menu list not only for the menu but also for the content it is possible to create a knowledge tree that is quite
easy to navigate and populate.
We are using (starting to use) this technique for a knowledge tree for our Information Management Group.
We here collect the very diverse information we are collecting and using on a regular basis. E.g. help,
instructions, guidelines, useful links, various tools and scripts and error reports.

2.

We used the following Quest Web Parts: qCascadingMenu, qListView, qListForm, qPanelMenu, qSelector.

3.

We are running SharePoint 2007 Server.

4.

What do we do with all the cool and useful information we find, with all the solutions we find and develop?
Where do we put this information so that we can find it again? And maybe even other people can find and
use it?
We have tried many different solutions, and none of them have really worked. It has been too cumbersome
to fill in the information and taken too long to find it again, so no-one has really bothered. A standard
SharePoint list we created in 2009 almost 2 years later only had one entry!
With this application it is so easy to enter and structure the information and to find it again that the gains
far outweigh the costs, and we expect to use it extensively in the future. If the screen dumps look a bit
sparse its because the application has only been used for the last week or so.

5.

For this application the most valuable features of Quest Web Parts was :
the cascading menus ability to show everything at a glance;
the advanced search functions which includes search in rich text fields;
the ability to use calculated fields used e.g. for some of the hyperlinks;
the Custom Display function, in this case used to add intelligence (javascript) to create the ID for
the next menu item and add it to a hyperlink URL;
the ability to use predefined/calculated values when you create a new item taking values from
e.g. URL parameters;
the ability to easily create parent/child views and relationships even within the same list; and
the ability to use relative links, meaning anything developed on this site easily can be copied to
other sites.

6.

On the following pages are four screen shots of our application:

Figure 1:

The main page

Contains the following 6 Quest Web Parts that show the menus and the information hierarchy for a selected item:
1. The panel menu showing the top 2 tiers of the menu;
2. The selector picks up the current item from the URL (or from a session variable). Passes the necessary
filters to web parts 4-6. This web part is normally hidden;
3. The cascading menu shows the entire tree structure see figure 3;
4. A standard list view shows information about the parent item. Using the list as a dependent list to itself
allows the display of children in child view. Background colors have been changed using style definitions
in the custom display of the web part;
5. Information about the current item displayed in the custom display of a list view web part. A standard list
form could have been used here instead, and
6. The children of the current item displayed in a list view. Their children again are displayed in child view (not
expanded). Observe the Create New Item link at the bottom. It is created in the custom display of the list
view web part. A javascript function calculates the ID for the next child item (increments of 2 to leave space
for reorganization later) and passes this on as an URL parameter together with the menu ID of the current
item. In the case shown the link looks like this: /New.aspx?NID=03_05_11&PID=03_05&MID=12.

2.
3.
1.

4.

5.

6.

Figure 2: The create new item page

The Menu ID and Parent Menu Id are already filled in based on the URL parameters passed to the page, but can be
changed if desired.
The Target URL is a calculated field that includes the ID of the new item. It is displayed as blank in the screen shot
(since there is no ID defined yet), but is entered correctly when the item is saved.
This automation is the big advantage of the application no need to remember or even think - and no risk of errors.
Just enter the title and the description and the rest takes care of itself.

Figure 3: The cascading menu

Displays the entire hierarchy branch by branch as you move the mouse. Only one click (and page update) needed to
find the information you are looking for. As fast and easy as it gets.

Figure 4: Standard view/search

Since its a standard list that is used for the menu other more standard displays are also possible. Like
this list/search view, where the possibility to search/filter a rich text field is used

Stockholm, June 30, 2011

Kim Forchhammer
Golder Associates AB
Sweden