Fluid UI | Back Button Considerations

I wrote about the Back button considerations for Fluid development in a previous post.

If we navigate to any component, then by default PeopleTools would track this navigation in the psback cookie which is used by the Back button.

Also, if the component contains multiple pages and if we navigate across pages within the same component, then those navigations are not included by default in the navigation history.

Demo

For the purposes of this demo, I am using the same component which I created for one of my previous posts - Fluid UI - Working with Grids.

Project: https://github.com/SasankVemana/Fluid-UI-Grid-Demos 

As we can see in the example, the Back button does not record any of the internal page navigations within the same component. This is actually the expected/default behavior and should cover most use cases because it is not commonly a requirement to track the internal page navigations.

But what if we want to track the page navigations within the same component in the Back button history?

There is a very simple option to do just that.

Component Properties > Fluid (Tab) > Component Attributes > Page Navigation in History (Property)

Demo

In the above demonstration, we can see that setting the 'Page Navigation in History' component property allows us to track the page navigations within a component (if required). This can also be programmatically achieved using the PeopleTools built-in 'SetTransferAttributes' function as described in my previous post here.

PSPRSMNAVINFO - Portal Menu Navigation in SQL

Last week, I worked on a requirement where I needed to find all the components that are part of a role (or a list of roles) including the Portal Menu Navigation Path if it exists. It is easy to get the list of components that are part of a role but it is not really straight forward to qualify that information with the actual Portal Menu Navigation (if it exists).

 In the past, I used the following query to return the Portal Menu Navigation Path for a Component. The query mines through the Portal Structure and Content and presents the navigation hierarchy in the result.

As we can see, it will not be easy to re-purpose this hierarchical query and expand it for my requirement.

While poking around on this topic, I stumbled on this gem of a table PSPRSMNAVINFO that, I believe, was introduced thanks to the PeopleSoft Search Framework!

Here is what we can see in the Definition Properties of this record:
"Holds the Navigation Path to the given target crefs registered in Portal Registry. Holds only effective and non-expired target crefs.
Used by the Portal Menu SES Search.
Updated every schedule of search index file"

From my understanding, it appears that this table is used as part of the PeopleSoft Search Framework - PTPORTALREGISTRY Search Definition. Also, the App Engine library PORTALPATHAE is responsible for populating this table with the navigation path information when the search index is built.

PeopleTools > Search Framework > Designer > Search Definition (PTPORTALREGISTRY)

PeopleTools > Search Framework > Administration > Schedule Search Index

To identify the last time the PTPORTALREGISTRY search definition index was built, we can query the table PSPRSMPATHSTAT.

If for any reason we don't have the Search Framework enabled and we still want to take advantage of the data in this table, then we can simply populate this table by directly running the PORTALPATHAE App Engine Library from App Designer. Since I was testing this on a Virtual Box installation of a PUM image (CS 9.2 - Image 4), I did not have Search enabled/configured. I ran the AE from App Designer as follows:

Now, let us see how we can use PSPRSMNAVINFO to get the Portal Menu Navigation information.

The best part about this table is that it allows us to directly retrieve the navigation path for a component without having to deal with the hierarchical structure in PSPRSMDEFN. This makes it easier to use/expand this information in other queries.

Here is how I extended this information to create a query that retrieves all components in a role along with the Portal Menu Navigation Path information (if it exists).


Github link to SQL Queries in this post:
https://github.com/SasankVemana/PS-Portal-Menu-Navigation-Queries

Portal - General Settings - Navigation Options

If we login to a Campus Solutions 9.2 PUM image (CS 9.2 PUM 4 in my example), we will notice that we have the old left hand navigation menu for the Classic pages even though we are using PeopleTools 8.55+.

How is this available only in Campus Solutions and not in other application pillars?

This is because of the Navigation Options - Type setting under PeopleTools > Portal > General Settings which is set up differently in Campus Solutions. If we want to enable the left hand menu navigation then we can set it to 'Left'. If we want to disable it, then we can set it to 'Drop-down'.

PeopleTools 8.55+ - Fluid UI - Drop-Down Menu/Breadcrumb Navigation vs NavBar/Navigator Conundrum

In this post, I hope to bust some of the myths around the drop-down menu navigation which is "technically" going away in PeopleTools 8.55. There has been a lot of focus on the disappearance of the drop-down menu/breadcrumb navigation as it is not available by default in PeopleTools 8.55 which uses the Fluid header and navigation instead. I have seen several customers (here is a link to just one example of many in various forums) wanting to put it back just the way it was! Note: There are options to do so.

I could understand some of the reasons why customers might want to hold on to the older method of navigation. For example, project timelines and lack of time for managing the change, need to re-write user manuals/guides/documents, training/education, only a small subset of power users/admins use the system so why change?, etc.

A big part of the transition to the Fluid navigation is education which involves recognizing the reasons for the change and the benefits of using the Fluid navigation mechanisms which is very intuitive. For starters, Fluid navigation is more than just the drop-down menu! It involves Homepages, Tiles, Dashboards, WorkCenters, Activity Guides, Related Content, etc. There are plenty of very good resources that demystify the new navigation paradigm in Fluid. Here are a few:

PeopleSoft VFO: https://www.youtube.com/watch?v=oXdvD9rKO_U
PeopleSoft VFO: https://www.youtube.com/watch?v=o5-wQ2dHKsw
Oracle Blog: https://blogs.oracle.com/peopletools/entry/fluid_header_and_navigation_is
LeanItDesign: https://leanitdesigns.wordpress.com/2016/03/28/fluid-navigation-adopting-to-the-new-normal/

In spite of all these attempts to educate our customers and end-users, I am sure there will still be a few who simply insist on having the drop-down navigation. There may also be some users (e.g.: power users) who might legitimately require the drop-down menu style navigation. Here are couple of ways I would sell the Fluid navigation to those users:

Pitch 1: The drop-down navigation is not gone! It is now in a brand new location (NavBar > Navigator) and expands vertically in Fluid. When we use the Navigator, it also remembers the Folder location that was last visited - including 'Back to Previous Folder' and 'Back to Root' capabilities. Effectively, all the functions of the drop-down menu still exist!

Pitch 2: Let us say, my users are not impressed with my previous pitch. They tell me that we now have to click on the NavBar and then click on the Navigator to initiate the menu. Previously, we only had to click on 'Main Menu' and out pops the drop-down menu navigation. These are the hard to sell folks that I am talking about!

For example, let us compare the navigation to the 'Web Profile Configuration' page.
In Classic: Main Menu > PeopleTools > Web Profile > Web Profile Configuration
In Fluid: NavBar > Navigator > PeopleTools > Web Profile > Web Profile Configuration

Granted, they have a point! They have one extra click to complete the navigation (assuming the Navigator was not previously initialized/toggled).

Here is a simple workaround for that! What if we make the 'Navigator' active/selected and expanded when the NavBar is initiated (except for the Small Form Factor devices)? Will this make these users happy? Hopefully, because now the Navigator behaves exactly the same - if not better - when compared to the Classic drop-down menu!

This requires a minor customization as follows:

Step 1: Create a JavaScript Object

PeopleTools > Portal > Branding > Branding Objects

JavaScript: CSK_NB_INIT_JS


Note: I am using requireJS (for managing my jQuery module dependency) that is available as part of Oracle JET in PeopleTools 8.55. You don't necessarily have to use this approach but if you would like more details, then please refer to my posts on Oracle JET (Part 1, Part 2, Part 3 and Part 4).

Step 2: Inject CSK_NB_INIT_JS when PTNUI_NAVBAR page/component is loaded

In my case, I am simply using the Global JavaScript Injection Bootstrap that I described in my previous blog posts. I updated my cskInjectJS function to include the following lines of javascript to load CSK_NB_INIT_JS (created in Step 1). I also check if the current request is not from a small form factor device to avoid auto-selecting the Navigator on small screens like phones (which would cover up the entire screen and might not be desirable).

Update JavaScript Function: cskInjectJS


Note: The following links provide the full JavaScript source code as of this post: CSK_FL_BOOTSTRAP_JS and CSK_INJECT_JS.

Results:

NavBar Initialization Before Customization:

NavBar Initialization After Customization: