Monday, September 5, 2005 | News | Content Management
The following case study, by Martynas Storasta of the Lithuanian Labour Exchange, gives us a fascinating insight into the process they adopted for choosing an open source Content Management System...
By Martynas Storasta
Deputy head of IT division, Lithuanian Labour Exchange
An Introduction to the Lithuanian Labour Exchange
The Lithuanian Labour Exchange (LLE) is based at the Ministry of Social Security and Labour and its 46 local labour exchange offices began their activities on 1st of March, 1991.
LLE implements state employment guarantees on the labour market, provides assistance for job seekers in finding jobs, provides employers with a skilled labour force, involves registered job seekers in specific employment programs (vocational training and retraining, organisation of own business, placement into public works, establishment of new jobs, activities of job clubs) and pays benefits for the unemployed.
The first LLE internet site was set up in the early 1997. Another 46 �subordinate� internet sites were also set up after 2 years. They represent each territorial office of the LLE and are widely used for information publishing about the local (territorial) labour exchanges.Our organisation has one specific department, �Information Systems Organisation Division�, which is directly responsible for all the Information Technology issues. Each territorial office has its own IT specialist.
In total there are more than 1,500 employees on the whole working at LLE (including territorial offices), almost 1,000 of them work directly with clients � conducting interviews or providing other support for the unemployed.
To date, we have used Plone for around for half a year. Before we chose it, the logical sequence of events for us was:
- The presentation of the idea to the LLE (this was a period when we had no facts about any CMS).
- Investigation into available Content Management Systems
- Implementation of the selected CMS
- Usage
General remarks and introduction
The first investigations into selecting a CMS began early on in the summer of 2004. At that time we didn't have a clear vision of what it should be like. Our main requirement was to create a strong and effective tool for strengthening internal communication between our staff. One of the most important features we were searching for was a good mechanism for user authentication and rights management.
The first idea was to select some well known solutions from the pool of PHP based Content Management Systems. We tried several sophisticated systems, starting with Mambo and finishing with TYPO3.
When we tried Plone for the first time it seemed to be quite mysterious from the inside, but looking at it from the outside seemed to be surprisingly clear and easy to understand.
Here is a short review of things we liked in this system:
- It had a very straightforward installation (we tried only Win 32 edition). The install file was the only one needed to start using Plone immediately. This was important to us as we were going to install it locally in every office,
- The ability to set up "dummy" content to let users quickly see and recognize usual content types.
- The clear localization solution. As soon as we had modified one special file (.PO) and added it to a specific folder, all users who had their Local settings switched to Lithuanian had the relevant parts of the interface translated. It�s good that there is a way to change the language depending only on the settings of the browser languages.
One thing that proved to be useful from the start was the users and groups folders. The idea behind that is very simple but at the same time it is an effective groupware solution. This means that every new user gets his own folder (similar to Windows �My documents� folder), where users may store every personal data files and notes. As our purpose was to provide users with the most convenient and easy to use solution, we really liked this feature and expanded on it later on.
Other things to mention, which were a definite "must" for our intranet solution were:the Calendar slot (a small section of the main screen), news slot, upcoming events slot, last added elements and favorites - this one is very special, because anyone may customize it depending on their needs.
Implementation scheme and start of usage
Our organization had not been using any other intranet solution before this, so it was our first experience of both an intranet and Plone.
We installed Plone on one server centrally. This machine has 1GB of RAM, and so there were no big problems with increased cache memory usage. On the whole, our organization has almost 1,200 employees, with the largest share of them belonging to our territorial offices. At the central (top) level there are around 60 active employees, who have to be accessing intranet resources frequently. Others, from different territories, required reading access only, and only on a few special occasions the possibility to write or upload content. According to this organizational structure, we created users for each individual at the central office and one user per territorial office (there are 46 of them in total). As mentioned earlier, each person from our central office has the possibility of uploading his own content, and making it visible or published.
As the main usage of the intranet began only half a year ago, I can describe succinctly the main problems or shortcomings we had during this short period. The most evident problem is that users forget their passwords (a problem I�m sure other companies face too!). After a while we made a customized solution where a user needs to login only once. After that, if they do not log off manually, there is no automated logging off process. This helped us very much. By the way, Plone has an automated password reminding function, so the issue is almost solved.
Another thing that causes problems is that our users are not used to filling in forms, and usually they omit something or choose some different items instead of those they really need to create. This is a question of experience and better training (we already arranged a local training session twice).
The third major problem is the slow change of mind in terms of intranet utilization. Not everyone agrees that this kind of information publishing or exchange is the best, especially when compared to email notifications. Yes, of course it lacks some mechanism for notifying users about the new items, which are relevant for them, but we think we will manage to develop this type of solution over time.
Speaking in general, Plone is serving our needs very well, mostly for smaller groups (divisions) information exchange and management. One big issue which is worse when comparing with some PHP management systems is that is that Plone does not have a clearly defined and documented connection to SQL server databases. While testing an upcoming version of Plone we have managed to create a special query page which connects to the specified SQL database. Maybe in the near future we will get more information about that, but at the moment usage of external database data is somewhat restricted and unclear.
Plone deployment and user training
We started using Plone as our intranet content management solution from September 2004. It was quite easy to set up and start running. The first thing to do was to change some interface elements like logo, calendar, header and footer. Moreover, there was a need to create a basic menu structure.
The whole set up process took around 2 weeks, later we just tried to make some smaller changes and improvements to the site. One thing we had to do first was to create menu items. This procedure was really one of the easiest things to accomplish, just like creating new folders in Windows Explorer. The second step was to add some content to the menu items. That was also not a very big deal. It is worth mentioning that after translation of the main PO file there were already basic help functions. Why should I emphasize that? When comparing with other CMS, this was the only one to have extended help included into the interface itself. It means that every user making things in this environment for the first time does not have to search for help in other sources. Each field which has to be entered is described shortly, for example "short name" which has to be clear, without special symbols, etc.
So by doing this kind of primary user training function, the CMS solution has quite a shallow learning curve (i.e. it is easy to learn to use it from a scratch). Besides the earlier mentioned groupware solution, which creates a separate folder for each group item, there is a personal folder. I want to mention it repeatedly, because it has a special link. As a user logs in, he has a first time "salutation" with a link to that folder, or alternatively may use a special link to this folder in the user specific menu. That is an interesting point, because we tried to deploy such kind of solution, when the same properties (I mean privacy and availability to freely create content) was given also to the group folder of the specific user. In this case, a user may decide � to create content for personal use, or to share it with a group. In our organisations case, groups were logical units for organization divisions, so that was not a big problem to decide upon which user should belong to each group. When talking about group membership it is also important to say, that one user may belong to several groups. This was extremely useful in our case, because some users had to be given more rights, but at the same time they could not do everything as administrators. For this special case, there was created additional group, called "reviewers", where some responsible people were put.
User interface review of Plone CMS
On first impressions, it seemed to be quite clear even for a novice user, and it remained so all the time. Very light, clear structures and intuitive design is reminiscent of a typical Windows Explorer window. Colors and symbols used in it are understandable and easy to remember.
There are other design or usability issues worth mentioning:
- Color coding of editable elements - users can easily distinct editable and non-editable elements
- Selected items are shown in contrasting colors and additional path for better navigation is provided
- Mandatory form fields are marked with an easy to distinguish red dot
- Adding and editing content is fully integrated into a preview (or live site) interface. This is very efficient when going through user training - there is no big visual difference from using and adding content. Just one green color means it is available for editing
Special objects in Plone CMS
The special objects were not that important at the beginning, but as time passed we found that there was a need for some specific content or integration solutions.
One of the first and maybe the most successful was a kind of "link with content" solution. I read about it in one comment at the www.Plone.org site. The idea behind it is very simple - you have to copy and modify one type of element to work as another. So when we wanted to make integral solutions, where some other internet pages had to be shown inside the intranet, we applied this kind of thing. The result was almost perfect - we have got our usual intranet interface and inside it there is another page shown with its native content. What is most interesting is that it did not depend on whether it was internal or external content.
One notable way of using this newly developed content type was to show a mail or a calendar view from an existing Exchange server. This allowed us to share and show a fully functional view of another internal content that had not been used in this way before. Moreover, it helped users become less dependant on the standard Office Outlook interface.
Another special object we introduced was a version of a standard additional Plone product called "Content panels". This product allows you to show more pages or "screens" on one page. This is a wonderful idea, just to put it in the front of an intranet site, with a purpose to let users find out how many different things they can do with the help of a newly developed intranet.
Several things were used as standard Plone features, for example "topics". They are used for finding and displaying specific information. I�d prefer calling them simply �filters� or �query tools� for content already created with a CMS. The area of using them is expanding. We decided to use topics for classification of different kinds of documents, for example, each division has their own "space" for content creation, but we need an area where all this content would be visible for everyone and in its entirety. So we chose to use these "filters" to grab the link of each "file" element in our site, which has some specific words in description. It now works fine: one drawback of this feature is incompatibility with date intervals, but at least it is serving for us in other matters.
At the time of writing this, we have worked out a method to show documents of the last week, using the topic feature. So, as I said before, it is helpful and is being constantly developed.
FTP or WebDav access to the Plone site
This type of solution is one of the biggest functional advantages against some other competitors. In our organization we have tried and constantly use uploading documents and other files (especially photos or pictures). If this upload process would be impossible without the use of FTP, this procedure would appear one of the most time consuming things in the whole publishing process. So we used it hard; without any big obstacles. Maybe one small disadvantage to mention - this CMS does not allow the use of some special Lithuanian characters as a short names (those which appear in the address line), but still we found it functional. For example, if there is a need to create a large photo album, we create a photo album object and upload all necessary images using FTP access.
There is also another option to upload and publish files - that is using some other applications, like Microsoft Office or similar. We are also testing ways of publishing information directly to the intranet, even without using CMS native publishing functions. But this is not the issue of my paper; I will just leave this question saying "yes, Plone does work with publishing features from outside applications".
Local folder and file storage solutions with Plone
As we started using more advanced options with Plone, there was a need for a better or clearer file storage and backup solution. Therefore we tried an additional product, called LocalFolderNG. Of course it was a useful thing to have, especially in the case when you wanted to upload a large quantity of files (at that moment we did not have any idea about the FTP access to the Plone native folder structure). We have used it for a while just for that purpose. Later on I have found that the same product may serve as an additional source for showing some externally created and saved HTML files. It really was a new application field in our organization. For example, we had special cases, when there was electronic content already created and we did not want to recreate it once more with Plone.Subsequently in this case we used a LocalFolderNG item, afterwards we just linked the external core file (like index.html) with separate item or text link and it had worked perfectly. Nevertheless it was a great functional improvement, this solution had a small drawback - people who used it for the publishing purposes had to make a direct connection to the server where Plone was installed. So this might be called a partially good solution or just the good one in the case of smaller organizations with one responsible person for content management.
Just a few words about file storage and backups� File storage was something mystic from the first sight. It seemed that all information saved in data.fs could not be structured or "disassembled" in any other way. But after a while we saw that there was another method for viewing files inside Plone - this was my already reviewed method of FTP or WebDav access.
Just to add few lines about our method for file handling... We chose to make backups weekly and the best method seemed to have a Zope exported file with extension .ZEXP. This looked to be meaningful, because such a file could be easily imported back into the server in a case of fall down or any other such emergency. Moreover, this type of file could be moved and successfully used in any other place, for example while developing; I had constantly done a part of my work on two computers on the different location. This approach looks similar to those called "nightly builds" of developing applications. You make some changes and then export the content again and import it in another place to continue the process.
Conclusions
The main field of application of Plone in the LLE as an intranet management solution seems to be the most rational decision because of a few things:
- This Content Management System (CMS) has all the necessary features required by the management of our institution (and even more potential inside) � especially user and group folders which are individual for each registered intranet user;
- There are lots of similarities in Plone and the usual �windows-like� interface, which all users are more or less familiar with, for example: Copy/Cut/Paste or folder browsing;
- It is a very flexible yet stable software solution � during the first year of intensive use no critical downsides have occurred, so we never had a situation when everything had to be restored from scratch;
- The system itself is backed up by the powerful Zope framework; even in the most desperate situations there was a good chance to use an import/export function and so many levels of �undo�;
- More than that, Zope empowers the use of templates (dummy sites), which are easy to distribute and install anywhere else within the same framework;
- It is easy to maintain, because each object you create can be �archived� after some period � so there is no need to do any sort of �revisions� of information published and make any manual archiving
In general, such great usability comes from the simplicity of user interaction inside Plone combined with Zope behind it. Compared to a complex Zope management interface (ZMS), Plone has an intuitive design and almost every novice user will guess where he or she should begin from � there are many helpful hints written for almost every field you need to fill in.
Our colleagues from territorial offices have nice ideas about implementing some kind of �specialised user workplaces� within Plone, so that each employee could see his main tasks and objectives from the starting page. This and similar ideas are already coming into life, so I hope that with arrival of a newer version (currently planning release candidate of Plone 2.1), we will make our users even more comfortable.
