Function1

Sure, the ALI navigation has always been incredibly customizable and pretty “future-proofed” – using Pluggable Navigation, you could tweak pretty much whatever you wanted in the portal. You know, you pick a section (“Above Header”, “Left of Body”, “Below Footer”), and you could programmatically create whatever HTML you wanted returned in that area. But it wasn’t perfect: You were still bound to those sections, and the HTML “outside” and “inside” those sections was still limited. Specifically, outside those regions, what if you wanted to customize the title of the HTML page, or add meta keywords to the tag for Search Engine Optimization? Or inside those regions, what if your 508 compliance officer complains about the phenomenally intricate table-within-a-table-within-a-table HTML that makes up the “body” of the page? Of course, this assumes you have programmers on staff who can even code the required custom navigation.

Enter Adaptive Layouts in 6.5. With the addition of a huge number of new Adaptive Tags (more on these later), you can now write the HTML however you’d like, and the portal will use that to generate the layouts. The different page sections are still there (“Above Header”, “Left of Body”), but you decide how these get placed in the HTML DOM, using Adaptive Tags and plain old HTML. For example, in the code below, the PT Tags are used to determine if any Profile Pages are available, then iterates through all them, putting them in a nested list inside a div tag.

When combined with the style sheet, you see the “My Profile” drop-down:

Under the covers, the way this all works is through page layouts, which are HTML/XML files that are stored on a remote server (the default layouts are just served up as static files from the image server, but these could even be dynamically generated layouts you programmatically create). There are different types of layouts for different types of pages, such as community, profile, and knowledge directory. And layouts can nest other layouts, so for example, the “Base Page” and “Community Page” layouts can share the same layout files for the header, footer, and body.

Sounds a little complicated, and the layout files actually can be a bit tough to interpret and manipulate, but this brings a whole new level of UI flexibility to the ALI portal, and it’s worth it. I remember having to write custom .NET code to tweak the style of the portlet header – no more, now that you can just tweak the HTML itself that goes into generating that header.

The last great thing about these layouts is that they’re specified per Experience Definition. That means that you can have COMPLETELY different look-and-feels for different user groups or sites within your enterprise. You just create a special “Layout” web service in a pre-defined folder, then it automatically shows up in the editor for Experience Definitions:

Again, the classic mode is still there – you can still write code if you want to. So LiquidSkin customers need not worry – the investment into the UI you’ve created won’t be lost. But I suspect that over time, you’ll find that while LiquidSkin made navigation customization so much easier for 5.x and 6.x, Adaptive Layouts make it even easier.