(For more resources on Plone, see here.)
Designing our intranet information architecture
No one uses a knowledge system (such as our intranet) if the information stored in it is hard to find or consume. We will have to specially emphasize on thinking about not only a good navigation schema, but also a successful one for our intranet. The definition of success is different for every interested group, organization, enterprise, or any kind of entity our intranet will serve. There are a lot of navigation schemas we may want to implement, but it is our task to find out what will be more suitable for our organization.
To achieve this, we will have to use both hierarchy and metadata taxonomy wisely. Obviously, the use of folders and collections will help achieve this endeavor. The first-level folders or sections are very important and we will have to keep an eye on them when designing our intranet. Also, we should not forget the next levels of folders, because they have a key role in a success navigation schema.
The use of metadata, and specifically categorization of content, will also play an important role in our intranet. The continuous content cataloging is crucial to achieve a good content search and the users should be made aware of it. An intranet where the search of content is inefficient and difficult is an unsuccessful intranet, and with time, the users will abandon it.
At this point, we should analyze the navigation needs of our intranet. Think about how the people will use it, how will they contribute contents to it, and how will they find things stored in it. In this analysis, it is very important to think about security. Navigation and security are closely related because most probably we define security by containers.
There are some standard schemas: by organization structure, by process, by product, and so on. By organization is the most usual case. Everybody has a very clear idea of the organizational schema of an enterprise or organization, and this factor makes it easier to implement this type of schema. In this kind of schema, the first-level sections are divided into departments, teams, or main groups of interest.
If our intranet is small and dedicated to one or few points of interest, then these must take precedence over the first level section folders.
Keep the following things in mind:
- Our intranet will be more usable if we can keep our intranet sections clean and clear
- Fight against those people who believe that his (or her) department is more important than others and want to assault our intranet sections
- Let them know that maintaining a good intranet structure will be more useful and will help contribute to its success
Second levels are also very important. They should be perdurable in time, interesting to users of all sections, and they should divide information and contents clearly. Two subsections shouldn't contain elements of the same subject or kind. For example, these might be a typical second level:
- Forums, tracker, or some application specific to the current section
All of these are very commonly seen in an intranet. It is a good practice to create these second-level sections in advance, so that people can adapt to them.
Teach people to categorize content. This will help intranet searches incredibly and will help create collections and manage contents more effectively. If needed, make a well-known set of categories publicly available for people to use. This would prevent the repetition of categories and the rational use of them.
Notice that there can be several types of categories:
Subject: Terms that describe the subject of the content
- Process: Terms that identify the content with the organizational process
- Flags: Flags such as Strongly Recommended
- Products: Terms from the products, standards, and technology names that describe the subject matter of the resource
- Labels: Terms used to ensure that the resource is listed under the appropriate label
- Keywords: Terms used to describe the resource
- Events: Terms used to identify events which are recurrent with the content
There are other metadata also which influence the improvement of the navigation and search abilities of the intranet such as:
- URL, the ID of each content
Don't forget to teach your users about content contribution best practices before deploying the intranet.
We and our intranet users will appreciate it a lot.
Once we have settled down on some practices which are best for information architecture, we should know how to use some interesting Plone features that will help us build navigation and sort the information on our intranet.
(For more resources on Plone, see here.)
The collection is one of the most powerful content types available in Plone. It's probably the most misused of all Plone's default content types because it is more complex and difficult to understand for non-technical or non-experienced users.
A collection is a real-time query for the ZODB (for the Plone portal catalog, to be more precise), and its contents are the results of this query. The query is defined by the user, who can also define how to display the results in the collection view. The query is executed with the rights and context of the current user, and the results are consistent with the user's rights over content. This means that a collection could return different results depending on the current user. Additionally, a collection is a content type, and, like any content type, has permissions and is assigned to a workflow. Thus, a collection can be for both public or restricted use.
We can use them to store recurrent queries in the database, for example, the News and Events, Plone's default view, is implemented using a collection. In both cases, we have a recurrent task of displaying all published news or events. The collection will collect all news or events objects published at that precise moment and will display them. In addition, the events collection will provide an additional filter for omitting all events that occurred in the past.
I can bet you can think of other useful use cases, such as a collection, that returns all the content authored by yourself to keep track of it easily. Or maybe a collection that returns all content contributed by the members of a team or workgroup in the last month (or year). The possibilities are infinite, of course. It's in your hands to find the right use case suitable for your need.
Use collections every time you need a non-hierarchal display of content and access the information in a direct and grouped way.
Creating a collection
A collection is as easy to create as any other content type, but there are some concepts on fields and configuration that are worth elaborating. There are two places where we can configure a collection: in the edit mode and in the Criteria tab. The edit mode holds all the common content type default fields along with the following:
- Number of items: The number of items to be shown in the results. Related to the "Limit Search results" setting.
- Limit Search Results: If this is selected, the results will be restricted to the number defined in the Number of items field
- Table Columns: Defines the columns to be displayed in the tabular view
- Display as Table: Displays the results in tabular way, with the columns defined in the Table columns field
But the most important setting of a collection is the Criteria tab. Here, we define the query on the database based on the fields or attributes of the target objects and its values. The criteria form is divided into two sections: the Add New Search Criteria and the Set Sort Order.
In the first one, we define the criteria. In order to do so, we need to inform what would be the object's field or attribute to search for and the value that we want to match the criteria with. This is usually done in two steps. First, define the field and the criteria type. For example, in Field name select Categories, and in Criteria type, select one of the three options that will determine how we will define the criteria: select it from a compiled list from all the available categories in the site (Select values from list), type a single category into a text box (Text), or type a list of categories separated by a carriage return (List of values).
Once we select one of them, the form will change to add the new criteria. The second step will consist of defining the category (or categories) that the criteria will match with. Almost all the criteria have this two step process. We can add as many criteria as we need. Don't forget to save any change made to the criteria settings.
The second part of the form is related to the ordering of the results. This order can be set against a field name and can be specified to be in the reverse order, if desired. Reverse order is useful when ordering according to dates, the most recent on the top of the collection's results.
Table of contents
This is a useful feature of the page content type. We can enable it through the Settings tab in the Edit mode. It adds a handy table of contents menu to the top right of the default view of the current page content type. It's formatted using the headings of the contents of the page, and is created and updated automatically. It also features relative links to the headings of the page. It's very useful on very large pages, where we want to keep access to contents clear and quick. We can see the result in the following screenshot:
We can enable horizontal navigation thorough all elements of a folder via this feature. It's useful in case we have a lot of information to show on a single page. We can divide this content into smaller pieces in order to make it more usable, clear, and searchable. Put each section into different pages inside a thematic folder on the subject we are writing (name it conveniently), and check the Enable next previous navigation checkbox in the folder's Settings tab in Edit mode, as shown in the following screenshot:
When we access any content in the folder, we will be able see the additional controls to navigate to the next or previous item in the folder. It works with any content type existing in the folder. The title of the next or previous item will also appear on the next/previous controls.
The sections are delimited by the heading styles included in a page, so we don't need to create a page for each slide. In fact, the heading style in Kupu or TinyMCE will be transformed to a h2 HTML tag that will be used by S5 to format the presentation. All content between h2 tags will be formatted as slides. The content of the h2 tag will be the slide's title and the content located between a h2 tag definition. The next one will be the slide's content.
A leading slide will be added automatically with the title, description, and author of the page. The S5 engine will also render basic controls over the presentation itself for navigating around the presentation's slides. Then it will close the presentation mode and return to the normal visualization mode.
Enabling the presentation mode
We can enable presentation mode by editing any page content type and then clicking on the Settings tab. The Presentation mode checkbox is available there. Once checked, a link will appear in the view of the page for a user to view the page in Presentation mode.
Formatting a slide
Following the most popular practices on how to construct a presentation slide, the presentation mode will not render text chunks or paragraph text. Slides are meant to display concepts, ideas, and summary information. For this reason, if we want to display content in the Presentation mode, we must format it with a style other than the Normal paragraph style. For example:
- Definition list
- Bulleted list
- Numbered list
- Pull quote
- Highlight (if not inside a paragraph)
We can add images too, if they are not inside a paragraph tag. It's possible that we may want to hack the HTML code in order to achieve the best results if we want to format a complex presentation. We can do this by triggering the Kupu's HTML view button. Remember that all content inside a p tag will not be rendered. If you want to make some previously created content presentation mode ready, it would possibly require some minor adjustments before it will show properly.
We can use this feature to add additional support information to the presentation in our page that will not be rendered in Presentation mode. By doing this, with smart usage of page formatting, we can write a page with two purposes: holding the detailed documentation of a particular subject, along with the presentation that consists of the summary and highlights of the subject.<>
We can take the default Welcome to Plone page as an example on how to proceed with Presentation mode. The following screenshot is the third slide of Plone's default page in Presentation mode view:
(For more resources on Plone, see here.)
Third-party content types—best practices
We've already learnt about how to use Plone's default content types wisely. Now is the time to talk about third-party content types provided by third-party add-on products.
Sooner or later, we will find ourselves browsing the downloads section on the Plone site and will be tempted to try a lot of products that promise wonderful features and incredible content types. We recommend you to follow some rules when dealing with third-party content types—firstly, don't rush into it and be careful.
A few golden rules
We should observe some golden rules before a third-party product is put in production. They are valid for all types of third-party products and not only for those that provide a new content type, of course. They are very simple and can save us from trouble:
- Find out who's the author (or authors) of the product, and how many other contributions they have made to the community
- Check out if the product is uploaded to the SVN collective repository (http://svn.plone.org/svn/collective), to make sure that all the members of the community can contribute and improve it
- Check how long the life cycle of the product is and if it's a final release
- The product must have decent documentation that would lead us to a better understanding of what the product does (and what it doesn't do)
- Check if the product has enough test coverage
- Always test the product in a development environment, and if possible test it with real data
Ordering the "Add new" content type menu
By default, all installed content types are shown in the Add new... menu, ordered alphabetically, but we can restrict the types of content that can be added. This menu has two configurable levels. The first level is the menu that unfolds when we click on the Add new... tab and shows the allowed types. The secondary one is a view that can be accessed from the item More... of the first level drop-down menu:
This allows us to seperate the most used or preferred content types from the least used or less popular ones. Thus, simplifying the allowed content types drop-down menu and making it more usable at the same time.
Believe it or not, this simplification usually provides a better user experience. If we make a proper selection of the more used content types (or those which we think are more appropriate for the user to use), the users will have more possibilities to find the right content type quickly. If we give them many possibilities, the chances of choosing the wrong content type is high. The user's confidence in the intranet will drop due to not finding a suitable content type for the job they require at first glance. In the end, this simplification provides a better user experience. If the user can't find the right content type from the first selection, the user will access the extended one in the secondary types view and continue with the creation of content.
The item More... will be displayed when we tell Plone which content types we want to show as primary types and which as secondary types. All users with the Manager role on a folder (except on the site root) will be able to access the item Restrictions.... It will be located in the new content type drop-down menu. This item will lead us to the restriction policy form. In this form, we can choose between Allow the standard types to be added or Specify types manually. The former is the default option; whereas the latter will open an additional form where we can specify which will be the allowed types and which will be the secondary ones. Specify the allowed (and primary) types in the upper part of the form and the secondary (the ones that will appear in the More... view) types in the lower part of the form.
Content type superseding
To avoid user confusion it is recommended to not maintain two (or more) content types with similar purposes. This includes content types that have similar fields, functionalities, or views. It's a good thing that all intranet users choose the same content type to perform the same kind of job.
If we still want to add the new type to our allowed content types, it's recommended to hide the creation option of the superseded type. Of course, all the content already created with the old type will be preserved, but the user will not be able to create more content using it.
We can use the portal_types ZMI tool to hide the old content type. To access it, click on the content type we want to hide. Inside the type form, the Implicitly addable? property controls the visibility of the content type item in the drop-down menu Add new.... Once we uncheck it, the content type will not be available to add.
It's also a good practice to inform the intranet users about the change, along with the new features of the content type and any significant information they might want to know.
Maintaining the intranet usability is a goal we have to continuously keep in mind. Making a lot of complex content types available in our intranet types, which are hard to create and consume, will lead to an intranet which will be hardly used. Even the more experienced techie users will end up not using it. Think about the interests of the non-technical users and you have a lot gained.
If we choose the right third-party products for our intranet, it will be easier for us if we want to upgrade the product itself or Plone. If a product has heavy community support, there is a probability that it will have good upgrade options between the versions as the product evolves. The same thing happens with Plone's upgrades. The product will be ported more easily if the product is well supported.
We have to be very careful about the content types we make available for our users. Failing to do so will lead to really hard upgrades, product conflicts, and user confusion.
In this article, we've covered the following topics:
- How to organize information on our intranet
- How to get the maximum out of Plone features, such as collections, previous/next navigation, and so on.
- Building our own Plone 3 Theme Add-on Product [Article]
- Content Rules, Syndication, and Advanced Features of Plone 3 Intranet [Article]