Tag: Portal

Intranet Portal Usability, From a User Experience Perspective

Posted by on July 25, 2011

The Nielsen Norman Group recently published a report on intranet portal usability based on 67 real case studies from enterprises worldwide. In contrast to other reports that typically offer vendor solutions, this report is seen from the user experience perspective, providing insight on what portals mean to users and how to deliver a portal solution that organizations need.

Jakob Nielsen touches on some important points from the report in his column. The overall trend for enterprise portals seems to focus on ways of making the existing features more robust and better managed as portals have become more widely accepted. The early definitions of portals being gateway access points have evolved; today’s portals can be thought of as a dashboard integrating all enterprise information and applications that employees need to do their jobs through a unified interface.

Interestingly, but maybe not too surprising, the biggest finding is that portals aren’t adding mobile features at the expected rate, at least not when compared to consumer apps. Most of the companies studied saw true mobile portals as being at least a few years out. Research has found that good mobile usability requires a separate design with a reduced feature set for mobile use cases, focusing on time- and location-dependent tasks, so it’s not enough that an existing portal is made accessible through phones since the UI is optimized for desktop use.

Since this report focuses on the user experience, it comes as no surprise that personalization is a critical component of a well-designed portal. The ability to integrate information from multiple sources can have its own disadvantages as the information can be overwhelming for the users, especially when it’s irrelevant. The more the portal serves up to the users, the stronger the need to curate what each person sees. Allowing users to customize what they see through individual user profiles provides an effective way display content relevant to each user.

Portals have long been known for its social features, but now they have also evolved into collaboration platforms. While most companies didn’t see a sharp distinction between the two, an easier way to distinguish the two is informal vs. formal collaboration, where formal content is officially managed and informal content is left to emerge on its own. This contributes to the issue of governance, which many organizations already struggle with. While governance may be a greater issue for larger enterprises, a key lesson learned is that organizations should plan the governance structure before starting a portal project. While there is no general governance solution that fits all organizations, they can look at governance solutions that have worked for others and adapt them to their own specific corporate culture and circumstances.

So while the portal industry has matured over the years, the focus now shifts to the user experience to create a solution that can be easily adopted and optimized. The full report can be found here, http://www.nngroup.com/reports/intranet/portals.

On a similar note, in one of our own recent webcasts (and at the Liferay East Coast Symposium back in May), we spoke on the topic of building and deploying a global intranet with Liferay, which touched on some of the same challenges that enterprises face when starting this type of initiative – personalization, governance, employee search. Our presentation is available for download here, http://www.slideshare.net/rivetlogic/building-and-deploying-a-global-intranet-with-liferay-8459841, and the webcast is accessible on our website, http://rivetlogic.com/resources/webcasts.

JBoss Portal Gets a Twist of eXo

Posted by on June 10, 2009

Today eXo Platform, a leading European open source company, announced the merger of its eXo Portal project with JBoss Portal to create an open source portal platform.

The goal of the new project is to forge a strong portal solution by bringing together the technical strengths of the two projects through the open source community.

According to eXo Platform CEO, Benjamin Mestrallet, “What has always been a challenge for any portal community or vendor is providing the right balance of robust infrastructure and engaging usability features. This collaborative project will strive to strike that balance and will work to create an enterprise-grade, open source alternative to expensive, bloated closed source portals.”

“The eXo portal has some impressive functionality in terms of ease of use, UI flexibility and straightforward management administration; JBoss.org’s current portal project has a robust engine, performance and security features, combined this collaboration project will help drive portal capabilities forward,” said Dr. Mark Little, Sr. Director of Engineering, Middleware at Red Hat.

What does this new portal product mean for other open source portal platforms like Liferay and Plone? Should they be worried? They may want to keep an eye out as eXo is contributing a new project to the JBoss community, eXo JCR, which is a “robust cluster-ready Java Content Repository that is standards based and a key component for the project”. Could this be seen a threat to other portal platforms which lacks the robust content management features that eXo JCR will bring?

It would be interesting to see how the new JBoss eXo portal platform fares with enterprises in their choice of portal and collaboration software.

Alfresco integration with JSR 168/286 portals

Posted by on April 15, 2009

At Rivet Logic Corporation I’ve been tasked many times to expose Alfresco features through a JSR-168/286 portlet hosted in JBoss Portal or Liferay Portal. Easy right? Not really, and here’s why:

Today Alfresco provides us with a couple of ways to do this:

1. Write a portlet and use Alfresco’s Web services API to expose the Enterprise Content Management (ECMS) features
2. Use Alfresco’s out-of-the-box Web script portlet to expose an Alfresco Web script

The first approach works but in many cases requires that you develop custom Alfresco actions since the Web services API does not cover the full feature set of AFS (Alfresco Foundation Services).

The second approach provides us with more AFS coverage but has one restriction that is not easy to work with. It requires that all of Alfresco be deployed inside the portal as a portlet application. So if you needed to deploy JBoss Portal running an Alfresco Web script portlet that exposes the MySpaces Web script, the deployment would look like this:

The problem with this approach is that it introduces scalability constraints. Namely, if you need to scale the portal you are forced to scale Alfresco with it and vice versa.

For the Web services approach we have an alternative thanks to our Remote Alfresco API rivet (RAAr). With RAAr we are able to make use of Web frameworks like JBoss Seam backed by rich UI component libraries like RichFaces to develop JSR 168/286 portlets that expose most if not all of the AFS features using a Java-based API that uses RESTful communication to provide a secure and scalable interface to Alfresco. One example of a document library portlet that we created using this approach is shown below:

On the other hand, if you need to go with the Web script approach you’re pretty much out of luck unless you’re willing to go with the deployment architecture shown above. The fact that there was no single solution for this problem was all the motivation I needed to create AWPr (Alfresco Web Script Portlet rivet). With this portlet we will be able to have a better deployment architecture that could be represented by the following diagram:

Here the portal and the ECMS are in two separate tiers and can be managed or maintained as such. This not only allows for better flexibility when scaling becomes necessary, it also allows the portal to expose Web scripts that are hosted in different geographic locations.

To make this possible I leveraged a custom authentication component that we wrote called STAr (Secure Token Authentication rivet) that could be plugged into an Alfresco authentication chain. With this in place the portlet can carry the user credentials from the portal to Alfresco, authenticate the user in Alfresco and retrieve a ticket that can be used during all subsequent interactions between the end-user, the portlet and ultimately the Alfresco Web script itself.

We recently released the first public version of AWPr under the GNU Affero General Public License.

The release includes two example Web scripts that, when installed and configured correctly in your portal (e.g. Liferay Portal), will look like this:

If you would like to know more about AWPr you can visit its wiki pages at the following location: http://wiki.rivetlogic.org/display/AWPr/Home