(For more resources on Liferay, see here.)

Designing the site—Painting the full picture

Whenever we get the requirements of the portal, we should first ask ourselves, how would the portal look when it goes live? This one small question will open a door to a lot of other questions and a lot of information which will be required to implement the portal.

You should always think of the end state of the portal and then start painting the complete picture of the portal. This approach is known as Beginning with the end!

Now, as we have just discussed the approach we should take while starting the site design, let’s understand what all information we can retrieve or get when we ask this question to ourselves. We will discuss about four main components of the Liferay Portal design.

Users

No matter what the size of the portal is—small, medium, or large—it will always be designed for the users. Users are in the centre of any portal application.

Let’s think of a very common portal . Just imagine that you have to implement this portal. You are sitting in your nice comfy rocking chair and thinking of the users of this portal. What all questions would you ask yourself (or the client, if he/she is with you) about the users of this portal?

1. Who will be using this portal?
2. Will all the users of this portal have same privileges? Or some of the users will have more privileges than the others?
3. Can we collect the users into any specific group?
4. Are these users organized in any kind of hierarchy?
5. Can the users leave or join this portal at a will? and so on.

Let’s discuss about the answers of the preceding questions and the information we can retrieve from the answers.

• If we want to provide an answer to the first question in only one word, then it can be—Users. It is quite obvious that the portal will be used by the users. However, if we go into the detail of this question we can get an answer like—all the employees of CNN, users from all over the world, John Walter who will be responsible for administration of the entire portal, and so on. So answer to this question will give us the information about all the players associated with the portal.
• If all the users of the portal have the same privileges, then it’s pretty obvious that every user will be able to perform the same function in the portal. However, this may not be the case with our portal, http://www.cnn.com. Here, we have end users who will come to the portal and will access the information; we can also have a group of internal users who can create the content. Similarly, there can be a group who can approve the content and other group can publish the content; there can also be users who are responsible for user management and one or more users who are responsible for portal management.
• So this kind of question will give us the information about different roles and permissions associated with each role in our portal. It will also give us the information that which user should be associated with what kind of role. This information is very useful when we are working on the security piece of the portal.
• If the answer of the third question is Yes then we can either create a user group in our portal or group the users into a specific role. This question will give us the information about user grouping in the portal.
• Now, answer to the last two questions will be discussed in more detail in this article. However, these questions will help us to determine if we should use an organization or community or mix of both in our portal. Every Liferay portal must have at least one organization or community.

Once we get the information about the users in our portal, we should think of the content next.

Content

No portal can exist without any kind of content. The content can be a static HTML, a static article, a video, an audio, podcast, document, image, and so on. To make the portal more effective, we have to manage the content properly.

We will continue with our example of :

• What kind of questions can we ask to ourselves or to the client about the content?
• What are the types of the content we will use in the portal?
• Where are we going to store the content? To Liferay database or some other external database?
• Do we have to create the content from scratch?
• Do we need to migrate existing content to Liferay?

And a few more…

I am sure you must be visiting many portals every day. Can you think of the possible answers to the preceding questions? Also, think of the information which can be retrieved from those answers.

• The answer to the first question can be—document, images, web content, video, podcast, and so on. This answer will give us an idea about the content types which need to be implemented in the portal. Some of the contents like web content and documents can be available out of the box in Liferay; while other content types like video and podcast may not be available out of the box. This information will enable us to determine the types of content and effort required to create the new content.
• The second question is a bit tricky. By default, Liferay stores the content into database. However, if the client wants we can store the content in some shared location as well. For example, storing documents into file system. Also, it requires high availability. You can refer to wiki about this on . An answer to this question will give us information like if we need to add any additional hardware or not, if we should do any specific configuration to meet the requirements, and so on.
• Answers to third and fourth questions will be mainly used for the effort estimation purpose. If a portal like site is using a huge amount of content and all of the content has to be built from scratch then it may take a good amount of time. If the content is already available, we need to consider the effort of migrating and organizing the content.
• We can also think of other questions like requirement of workflow, type of the flow, if staging is required for the content or not, and so on.

All of the preceding questions will give us a good picture about the content to be created or used in our portal. Once we are thorough with this section, it becomes easy to appoint someone to do content management design for your portal.

Applications

We have discussed about the user and the content of the portal. However, what about the applications which will be hosted on the portal? We cannot imagine a portal without any application nowadays. A portal can contain different applications like forum, wiki, blog, document viewer, video player, and so on. Let’s get a list of questions which you should ask yourself while designing the portal:

• What are the different applications required for this portal?
• Do we have any application available out of the box in Liferay?
• Do we need to modify/extend any existing application available in Liferay?
• Do we have to create any new application for the portal? If yes, what is the complexity of this application?

Liferay ships with more than 60 applications pre-bundled known as portlets. These applications are very commonly used in many of the portals.

When we ask the preceding questions to ourselves, we get the following information:

• Number of applications required in the portal
• How many applications are available out of the box? If we have more applications available OOTB (out of the box) then it can reduce the development time
• Scope of the project. Do we need any integration with external system or not?
• Kind of applications we have to develop from scratch

Once we go through the preceding set of questions, it becomes very easy to get a picture of the applications required in our portal. It will also provide us information about the efforts required to implement the portal. So, if you are managing a portal development project, you should definitely have this information ready before starting the project.

Security

Security is one of the most important aspects of any portal. When we think about security of any portal, we must consider access to the content and the applications on the portal.

You must have come across many of the portals so far. Some of the portals allow you to create your account freely; some of the portals require an authorization before creating the account while some other portals don’t allow creating an account at all. Also, there are some portals which display the same information to all the users while other portals display certain information to members only.

To put this in a nutshell, each of the portal has its own security policy and it operates based on that policy only. Once we have discussed/thought about users, content, and application in portal design, we should consider the security aspect of the portal.

Now, let’s think of some of the questions which we should normally ask to ourselves/client while considering security aspect of the portal.

• Can everyone freely create an account with the portal?
• Do we need to migrate the users from an existing user base like LDAP?
• Can everyone access the same information or we need to display certain information to portal members only?
• Can all the members of the portal access all the applications with the same privileges or certain users have more privileges over other members?

And so on…

When we get answers to the preceding questions, we get following information about the portal security:

• If everyone can create an account with the portal, then in that case we need to provide the create account functionality to the users. Also, we don’t need to do any authorization on account creation. If the answer to the first question is NO, then we need to either provide some kind of authorization on account creation or we need to remove the account creation facility completely
• If we have to migrate the users from an existing user base, then we have to think about the migration and integration. Liferay provides integration with LDAP. If the user base is not present, then we will end up creating all the accounts manually or provide users an ability to create their accounts
• If all the users (including non-logged in users) can access the same information then we will keep all the information on public pages but if we want certain information to be accessed by members only, then we might consider putting that information on the pages which can be accessed only after logging in
• If all the members of the portal can access the same information with same privileges then we will not need any special role in the portal. However, if a certain group or a set of users have more privileges over the other—like only content creators can create content—then we will have to create a role and provide the required permission to the role

When we think of the security of the portal, we are thinking about users and their access, applications and access to those applications, and other security-related aspects of the portal. It is very important to think about the security before implementing the portal to prevent unauthorized and unauthenticated access to the portal and applications within the portal.