7 Technical Questions to Ask in Your Portal Evaluation (Pt. III)

If you are struggling to choose the right web platform for your project, you’re not alone. There are many options to choose from, each claiming to be better than the rest. How do you choose for your specific project? The answer largely depends on the context of what you are trying to achieve. But whether you intend to build an employee intranet, e-commerce site, or anything in between, there are a few technical questions to consider.

This is the third post of a series designed to help guide you through some of the most important technical questions to consider in your evaluation. If you haven’t already, look through our first and second posts to get the full rundown. Hopefully, these questions will assist you in discovering the portal framework that is best suited for your project needs.

5. DOES THE PORTAL PLATFORM SUPPORT MULTIPLE RIA CLIENT FRAMEWORKS FROM AN ARCHITECTURAL PERSPECTIVE?

Technology supporting Rich Internet Applications has been around for several years making it essential for frameworks to support them. Some of the more prevalent RIA platforms are listed below:

  • jQuery – A popular JavaScript framework that provides rich support for creating client-side browser applications.
  • YUI – Another popular JavaScript framework, Yahoo UI Library is a high-performance and flexible framework used in highly interactive sites such as the Yahoo homepage and Yahoo mail.
  • AUI – Alloy UI is an emerging framework from Liferay that enhances YUI. It provides an additional library of user interface components built on top of YUI and provided with Liferay out-of-the-box.
  • GWT – Google Web Toolkit is a rich JavaScript client library that powers sites such as Google Mail and Google Maps.
  • AngularJS – A widely used JavaScript framework maintained by Google and built to help facilitate the development of single-page applications.
  • Vaadin – A Java server-side client framework, Vaadin provides user interface objects using a component model, similar to how Java AWT or Swing works.
  • Others – (ext-js, dojo, etc)

The RIA flavor you choose to develop your application is an important decision, but it is equally important to consider how the selected portal platform supports and integrates with the chosen RIA technology. Because the RIA framework is an integral part of the portlets you develop, it is important that the framework is supported from a foundational level of the portal. In other words, the application needs to be viewed systemically rather than looking at individual portlets, especially from a performance standpoint. This becomes more critical if your application needs to scale.

Portlets are designed to be self-contained, with all of their supporting resources meant to be included. When developing an entire application, however looking at the portlets as a system can result in positive performance outcomes. Consider three portlets that utilize jQuery for their user interactions. These three portlets would normally include the jQuery JavaScript libraries individually. If all three of them are placed on the same page, the libraries will be downloaded three separate times. This design will have serious performance implications. A good portal platform will make it easy to coalesce the portlets into a single library while providing the ability for it to be cached.

When looking at the portal systemically, good questions to ask include:

  • Does the portal platform provide the ability to combine all the RIA libraries into a single resource to minimize the HTTP requests needed for a single page?
  • Is the portal platform intelligent enough to combine requests across portlets using the same resources into a single resource request, rather than making individual requests?
  • Does the portal platform provide the ability to minify JavaScript resources served in order to decrease the payload size?
  • Does the portal platform provide the ability to cache the resource requests on the server side and eliminate the need to once again serve those resources by using a server response such as HTTP 304?

6. DOES THE PORTAL PROVIDE A CONTENT MANAGEMENT SYSTEM (CMS) AND CAN IT INTEGRATE WITH OTHER SYSTEMS?

Most portals and Rich Internet Applications combine functionality with content, usually a mix of HTML, documents, images or video. Earlier portal platforms relied on external Content Management Systems (CMS) to achieve this functionality. However, the convergence of CMS and portals is becoming more prevalent. Good portal platforms not only have their own content management system but also are able to integrate with external CMS platforms.

A native CMS within a portal platform should minimally support the ability to:

  • Import content from existing repositories into its own repository. (E.g., via import utilities that programmatically use an API)
  • Manage all CMS interaction with portal platform’s built-in permission system
  • Manage and edit unstructured HTML content using a modern WYSIWYG editing interface
  • Define and use workflows that are based on the jBPM standard
  • Define and use structured content types
  • The ability to create display templates for the structured content types
  • An easy to use interface for editing the structured content types
  • Preview content and publish it to staging and production environments
  • Automatically create versions when changes are made
  • Support automatic expiration of content based on a date attribute

As mentioned above, good portal platforms can also easily integrate with externally managed content. Since moving a significant amount of content from an existing CMS can be cost prohibitive, it makes more sense to manage, access, and serve the content directly from the external CMS. Ideally, the portal platform will support the external system through a native interface protocol. Alternatively, external content should be able to be accessed using the standard Content Management Interoperability Services (CMIS) protocol.

7. DOES THE PORTAL PLATFORM PROVIDE INTEGRATION WITH SOCIAL NETWORKS AND GADGETS?

Social Networking is an important feature to leverage in providing user experiences that return real business value. Leading online retailers are using YouTube, Twitter and Facebook to create powerful customer experiences that increase site traffic and business. Additionally, there is a plethora of third-party gadgets that have large user bases. Rather than write these applications and gadgets yourself, it is more efficient to use third-party gadgets directly inside your portal. A strong portal platform will be able to integrate with social networks in a variety of ways by leveraging the APIs already built out for those networks. This will allow the portal to integrate social networking features such as social bookmarking, embedding social content, and other sharing capabilities into portlets and CMS web content.

With this, we wrap up our post series of technical questions to consider during your portal evaluation. Be sure to check out our first and second posts in the series to get the full list. Of course, there are many questions outside of this series to consider during your evaluation period, many of which will pertain to your specific project context. But regardless of what you are hoping to build with your portal framework, if you hope to provide the most value to your users and help ensure your project’s success for years to come, make sure to take these questions into consideration.

 

Liferay Buyer's Checklist

If you want to learn about other factors to consider in a portal evaluation, we explore this topic in depth in our Liferay Buyer’s Checklist. It features a basic summary and a comprehensive checklist on evaluation criteria.

Download the Checklist

0