I’ll shortly be writing an article on optimizing the portal performance from the UI side and I thought it would be good to first touch on the subject of UI customization itself beforehand. In this post, I’ll also highlight some of the lessons we learnt over the years along a common journey with many fantastic and innovative customers. They have been the main drivers of several of the features now available in the portal. Although I vaguely recall doing something on one or two 4.0/4.1 portals, I would say that that my portal history really starts with version 4.5., so I’ll talk about UI customization from there onwards.
In the 4.5 version of the portal, whenever you had to customize the user interface, you essentially had to modify the ASP/JSP code of the portal web application. The advantage was that this was relatively easy to do. You could just edit the relevant asp/jsp files and voilà! Well, for portals deployed on the Unix platform, maybe you had to restart the WLS (at that time I think we were using Weblogic Server 6.1) but still, from the programmer’s perspective, this bit was easy to do. The problem was when you had to upgrade e.g. when you upgrade from 4.5 to 4.5 WS or its subsequent service packs (1, 2 and 3). Essentially you had to find the difference in the asp/jsp code between the vanilla version that you installed and the newer version that you are upgrading to as well as between the vanilla version that you installed and the changes that you had made. You then had to re-apply these changes programmatically to the newer upgraded version. Also, in the 4.5.* version, if say you had to deploy to multiple audiences, you had to install as many instances of the portal as the number of audience required. This meant that you had to apply the UI customizations programmatically to each of the instances. If all instances had the same UI customizations, once you've done the first one, the remaining ones would be relatively easier to do (since you just need to apply the same changes) but then certain trends began to emerge e.g. an internet-facing portal would be upgraded less frequently (because it's customer-facing, downtime may impact image, revenue etc.) and hence would frequently be found on an earlier version than say an internal portal etc. If the different portals had different UI customizations, you had to repeat that exercise for each.
With the 5.0 release, came the introduction of sub-portals and dynamic discovery. I'll touch on the subject of sub-portals in more details later. Dynamic discovery basically allows you to plug in your changes to the UI architecture without having to modify any of the core portal code or existing UI code. Say you were using the Java portal and you wanted a new navigation. You would essentially be developing the new navigation scheme using the relevant portal APIs, packaged it into a jar file, include it into your portal war file, configure the portal using the relevant XML configuration files to allow the portal to discover it and redeploy the portal application. This is described in more detail in the UI Customization Guide (check Chapter 9). When the portal starts, it will load the new configurations up at start-time. This approach had a couple of advantages:
- You could use your own JavaScript, build your new UI without having to overwrite the core portal or existing UI functionality
- By using the available interfaces, you would be using the MVC pattern
- When you upgrade, you don’t need to change your code all over again, as you had to do previously in pre 5.0
- It can handle multiple versions of the UI changes by giving precedence to the last loaded version
When you upgrade to a subsequent service packs, (usually) the installer would handle the customizations and include them. If for whatever reason it did not, then you just needed to reapply the customization in the previous paragraph. As UI customizations are usually a major part of a portal implementation, chances are that once developed and tested, they wouldn’t change that often. Hence, the major benefits were undoubtedly the ability to implement the UI changes using sound design patterns (MVC), switch navigation scheme at run-time without having to restart the portal and finally manage them through upgrades. The relatively harder bit was to actually implement, test and debug these customizations as you had to do these customizations in Java or C# (if you had deployed the .NET version).
In G6, the sub-portal feature from 5.0 was expanded into the experience definition. Essentially, you could now create new “sub-portals” at run-time (you could also do that in 5.0 by the way but there are more features in G6), allow the rendering of a new user experience based on a set of conditions. Say you are deploying an Intranet and partner portal. You could configure the experience definitions and the rules so that only employees can access and login into the Intranet portal whereas only partners can login into the partner portal. And the beauty with sub-portals is that you do not need to have multiple instances running. Physically, they would all be accessing the same portal but the user experience, including anonymous experience, login etc. could be different based on the experience conditions that you set. Some of the UI customizations e.g. login portlet, navigation bar etc could also now be done through the adaptive tags. However, it was still hard to customize other areas of the portal e.g. the search results page, the knowledge directory and thus you still had to implement these in Java or C#. During that time came LiquidSkin, a very popular custom navigation scheme offered by the consulting team. With LiquidSkin, you could configure several aspects of the UI using an XML file e.g the ordering of communities, navigation layouts, styles etc and you could change them on the fly without having to restart the portal either. For each experience definition, you would have a config file which would then control the overall look and feel of that experience.
In 6.5/10gR3, we improved the experience definition features with the introduction of adaptive layouts. Some of the improvements brought were motivated by a number of factors, including new trends in Web Design e.g. cleaner, modern UI (check Yahoo Design Patterns Library) but also generally the web e.g. lower payloads for the web pages while delivering faster and richer interaction of modern “Web 2.0” sites; the availability of sophisticated JavaScript frameworks like Dojo (which 10gR3 uses), YUI, JQuery and Mootools among others and customers’ desire to have the ability to use them to deliver rich user interaction capabilities; the improvement in mobile devices such as Blackberry and iPhones and their increasing ubiquity in the workplace, hence making the portal available on mobile channels was important (e.g. in the 10gR3, there’s now an iPhone layout and experience). Adaptive Layouts essentially provide you with the practicality of developing the UI customizations à la 4.5 while also keeping the pluggable nature of 5.x (to preserve changes after upgrade) and the experience definition features of G6. The adaptive layouts consist of XML/(X)HTML, JavaScript, CSS and adaptive tags and usually deployed on the imageserver and you can apply them per experience definition. Naturally, you can reuse existing layouts in other experience definitions. Areas where you can the UI using adaptive layouts include:
- Base Page (affects all pages)
- Knowledge Directory
- Portlet Layouts (My Pages + Communities)
- Portlet Selection (Flyout Editor)
- Profile Page Layouts
- Search Results Layouts
- Login Page Layout
- My Account Page Layout
- Error Page Layout
- Community Selection Layout
- Override portlet selection layout
I hope this overview of UI customizations is useful to you. I would like to thank our customers who made the journey through several versions, upgrades and 2 acquisitions with us and yet remain the driving inspiration behind it all. Finally, we are also doing a brief survey of BEA customers. Please tell us what you think and you stand a chance to win an iPod Touch.
Cheers,
Ali
