Navigation plan

I have the following plan for navigation, which still has a couple of holes in it. I am submitting this post requesting any feedback re my proposed method.

My navigation will drill down through levels of detail, e.g. from a site level through system and sub-system levels down to component level. This navigation is handled as follows. On each page, to drill to more detail, the user can select a displayed object. A row of buttons (one for each level) across the bottom of my header keeps track of where the user has been, and allows him to go back to where he came from at any level with one click.

I have a method which works for this navigation. The button which is used to drill down to more detail uses a script to populate a couple of SQLTags. These tags are used by the header button to move back up. It works, but might not be the most efficient method.

At each level, and for each possible screen to be displayed at that level, I want to offer a distinct set of navigation options. My plan is to have a navigation sidebar, with a fixed number of list boxes that correspond to groups of types of destinations (e.g “current status”, historical status", etc.). These boxes get populated via database query, using SQLTag values based on where you are and possibly how you got there. As an example, screens available from the “current status” box at the device level might include detail screens like “summary overview”, “fault annunciator”, etc.

I have a method which works for this as well. A script in each list box structures a SQL query to find the appropriate list items. Again, there may be a better method.

When the user selects an item in one of the lists, I want to swap to a new window, and often to pass some parameters in the process. The plan is that the target window’s title will be in the database alongside the selected list item (that originally populated the list box). When the user makes a selection, a script structures a SQL query to find the new window title, and swaps windows. The parameters will be from SQLTags, again based on current location. I am getting ready to write the script for this action, and it seems likely to get pretty complicated, so I thought to get some feedback before I jumped in.

Comments? Thanks.

Sounds like a good plan to me. Just make sure that the SQLTags that are used to keep track of where the user is / has been are Client tags, otherwise all of your concurrently logged in clients will share the same info.