Hublab - Virtual Knowledge Studio

Final Report
June 2008
Hublab
Towards online collaboratories for global
gathering in social and economic history
JAN KOK
IISG - Internationaal Instituut voor Sociale Geschiedenis
(Institute of the Royal Netherlands Academy of Arts and Sciences)
data
Table of contents
Acknowledgements
Summary
1. Introduction
2. Project goals
3. The research collaboratories
3.1. Institutional setting
3.2 Workflows
3.3. Desired functionalities
4. Comparing collaborative software
5. Installation and test of Liferay
6. User experience of Liferay
7. Lessons learned and prospects for future research
8. Project evaluation and financial report
9. Conclusions
2
3
4
4
6
6
7
13
14
15
16
20
22
25
Appendix 1: Questionnaire workflows and functionalities (Jan Kok
and Frans de Liagre Böhl)
Appendix 2:Technical report platforms comparison (Dutch) (Mario
Mieldijk)
Appendix 3: User guide Liferay platform (Frans de Liagre Böhl)
Appendix 4: Technical report Liferay (Dutch) (Frans de Liagre Böhl)
Appendix 5: Questionnaire user satisfaction (Jan Kok and Frans de
Liagre Böhl)
26
31
44
73
78
Acknowledgements
The Hublab pilot was unthinkable without the input of a large number of people, who
have brought their widely varying expertise into the project. On the technical side, I’d
like to mention Mario Mieldijk, Jip Borsje, Gordan Cupac, Ole Kerpel and Luciën van
Wouw. The participating collaboratories were led by Karin Hofmeester, Sjaak van der
Velden, Marco van Leeuwen, Richard Zijdeman, Kees Mandemakers and Tine de
Moor. For their advice and contributions to overall management I am grateful to Titia
van der Werf, Jef van Egmond and above all Frans de Liagre Böhl.
2
Summary
HubLab aimed to create a platform to support communication and data-sharing of
international collaboratories in social and economic history. The groups are
stimulated by the International Institute of Social History, but their members are not
affiliated to the Institute.
The international character of the groups required a user-friendly, ‘light’ tool that
would operate independently from the Institute’s internal system. In the first stage of
the project, leaders of four collaboratories were interviewed in order to gain insight in
software requirements with respect to internal workflows, communication, security,
version management of documents et cetera. Subsequently, three platforms were
tested (Sakai, Sharepoint and Liferay) on both the technical fit with the in-house ICT
knowledge and the needs specified by the collaborator leaders. In this test, Liferay
emerged as optimal candidate.
In the third stage of the project, Liferay was installed on five group sites. The leaders/
administrators were given a free hand to design their own platform and to stimulate
their group member to make use of it. Demonstrations of the tool were planned to
coincide with conferences or workshops.
The platform proved relatively easy to install and to use, but several programming
errors caused delay and, in the case of one or two leaders, reluctance to further
expose the research team to the experiment. Eventually, the user test of the platform
was largely limited to the administrators and the technical support team.
Given the high priority of the Institute to stimulate the creation of international data
‘hubs’, the study of best practices of both the collaborative research model and the
ICT support of it will continue. The platform itself will likely be improved by e.g.
adding demonstration videos, better navigation tools, integration with email. Even
more important is further exploration of data-sharing which is integral to the
collaboratory model. Thus, we will look into version management, a licence structure,
intellectual property rights and possibly online manipulation of data.
3
1. Introduction
This final report on the pilot project Hublab serves several purposes. Firstly, it
summarizes the original goals and planning as agreed with SURF Foundation
(section 2), it describes the actual implementation of these goals (sections 4 and 5)
and it evaluates the achievements in the light of the project’s proposal (section 8).
Second, it provides a detailed study of the collaboratories involved in the project. In
our view, the institutional and social aspects of the collaborative process deserve to be
taken fully into account when assessing the performance of technical solutions to
data-sharing and communication (section 3). Third, the report brings together a
number of scattered documents, such as technical tests and guidelines, which have
been produced in the course of the pilot test (Appendices). Last but not least, the text
offers a (self) critical evaluation of the test, in the sense that it weights and discusses
the relative merits of the selected platform Liferay and the input of the collaboratory
leaders and members, within the scope of a short-term SURF tender (sections 6, 7
and 9).
2.
Project goals
The project Hublab aimed to construct a supportive environment for a number of
collaboratories (both existing and new ones) geared at collecting and standardizing
research data in social and economic history. Three questions were central to the
pilot project. First, is it possible to optimize worksflows within online teams with
respect to the creation and manipulation of research data? Second, to what extent
does the platform enable and stimulate active participation, effective communication
and joint decision-making within groups? Third, what platform is optimally suited to
international research teams whose members are not to be integrated in the hosting
Institute and whose leaders require a great deal of autonomy versus the Institute’s
ICT department? Thus, how do these platforms function in a heterogeneous
environment of distributed data ‘hubs’?
The combination of these questions required an extensive, initial test of various
applications. In the first stage of the project, three collaboratory platforms were
evaluated: SURFgroepen/Sharepoint, Sakai and Liferay/Alfresco. The chosen
platform was to be installed in a test-environment for four different collaboratories.
Testing the software in different groups allows us to asses the importance of
institutional contexts, differences in workflows as well as group dynamics in the
implementation of communication tools.
The collaboratories involved number between 20 and 40 participants scattered
around the globe. The groups are:
1) Global Collaboratory on the History of Labour Relations in the period 1500-2000,
a worldwide ‘census’ of labour relations;
2) History of Work Information System,; a working group devoted to creating
uniform codes for historical occupational titles (also known as HISCO);
3) Towards a global history of life courses. Creating a network for the development of
data structures for standardized longitudinal historical data, a two-year project
involving an effort of managers of large databases to devise a joint structure for
historical micro-data;
4) Labour conflicts, a collaboratory building a central database on labor conflicts
(strikes and lockouts).
4
In Januari 2008 a fifth group requested to participate in the pilotproject:
5) Data infrastructure for the study of guilds and other forms of corporate collective
action in pre-industrial times, a collaboratory around the systematic collection of
data on guilds (1300-1800) in countries such as Italy, China, Turkey, England and
Low Countries.
The Hublab pilot project was planned as follows.
The first stage November-December 2007. This stage consisted of two Word
Packages. WP 1. ‘Inventarisation of workflows and functionalities’ aimed to report on
the workflows within collaboratories and to query their leaders on what they would
consider an ideal platform for their groups. The report, to be completed by late
November 2007, formed the input for Work Package 2 and was also disseminated to
the Surf tender community (Deliverable 1). WP2. ‘Comparison of collaboratory
systems’ aimed to find the most suitable platform, given the wishes of the teams’
leaders and the constraints of the Institute’s ICT-department. The WP implied the
initial construction of a scorecard template with weighted testcriteria related to on
the one hand the infrastructural environment (a.o. openness of the architecture and
technical and administrative demands). An important criterion was that the
Institute’s programmers should be able to develop new applications within the
platform and guarantee lasting support. Thus, the platform should match the inhouse knowledge of php, apache, java, mysql et cetera. On the other hand, the criteria
were related to general functional demands for data-sharing collaboratories (a.o.
communication, workflow, datafile sharing, version managment, rights management,
repository characteristics). The ICT-staff responsible for this WP installed and tested
three different applications: SURFgroepen/Sharepoint, Sakai and the Open Source
package Liferay, that was also tested on the possibility for integration with the open
source content management system Alfresco. The result of the test, Deliverable 2, was
a technical report to be completed in December 2007.
In the second stage, Januari 2008, the actual pilot was to be prepared by installing
the selected software in four (later five) collaboratories (WP3). This also implied a
new round of discussions with the hub-leaders on what content should be migrated
from their existing sites to the new environment. The platform (Deliverable 3) was to
be accompanied by a user guide, a configuration management procedure and an
(internal) test-plan.
In the third stage, February-May 2008, the actual test (WP4) was to be performed in
the research practice of the collaboratories involved. The intention was that each
group would demonstrate the platform at a workshop and discuss its usability in
online questionnaires and on the sites’ forums. The leaders were supposed to provide
their own reports on the platforms’ performance, and to incorporate in their reports
the experiences of the group members. At the end of the project, their reports were to
be consolidated in a single report with conclusions and practical recommendations
(Deliverable 4).
Two final Workpackages covered the entire period of the project. WP5 Knowledge
dissemination intended to distribute the results of the project among interested
parties. One outlet was formed by the Surftender blog, to which contributions on
Hublab were sent. Another intended outlet was a Hublab webpage and contributions
to discussion lists and professional journals (Deliverable 5). Finally, WP6 covered
the project management, which implied ensuring the timely completion of tasks in
accordance with the controlling document, maintaining contacts with SURF and
5
contributing to the tender meetings, and preparing both an interim and final report
(Deliverable 6).
3. The research collaboratories
3.1 Institutional setting
The project Hublab is placed firmly in the research strategy of the International
Institute of Social History. As formulated in the Strategienota 2007-2010, the
institute aims to play a leading role in worldwide research on economic and labour
history, by supporting international teams of peer researchers collecting and
analyzing data. The immediate stimulus for Hublab came from a KNAW grant for the
project ‘Global Hubs for Global History’ (September 2007-December 2009). In this
project, the Institute aims to improve the digital infrastructure for collaborative
projects in its field. More specifically, the project entails upgrading existing databases
into data ‘hubs’. A datahub is seen as a virtual meeting place for researchers and a
repository for their data. It offers a platform for their cooperation, links to
documentation and to publications concerning the project and offers access to the
data that forms the core of the research. The datasets currently managed by the IISH
deal with wages and prices, life courses/life chances, guilds, labor organizations,
strikes and labour relations. Each of these datasets offers insights into specific
elements of global economic and labor history. Furthermore, in their combination
they allow for entirely new research into the dynamics of long-term global processes.
In order to stimulate the comparison and combination of these datasets, efforts are
directed towards improving their interoperability through standardization, improved
documentation, georeferencing et cetera. Building an infrastructure of related
research databases with global data presupposes optimizing cooperation between
peers on a global scale.
Improving the ‘hubs’ is a clear priority of the Institute. However, the project Hublab
came at rather short notice, which meant that scheduled work had to be shifted,
which was not always feasible. This has caused some delay in Hublab’s progress (see
also section 8).
In addition, three other organizational aspects are relevant for an evaluation of
Hublab
(1) Selecting the platform and installing the pilot environment required a – for the
institute – unusually intensive cooperation between staff of the departments of ICT
and Digital Infrastructure and researchers. ICT staff were responsible for the
hardware involved and for installing the platform, the staff of Digital Infrastructures
had to support the platform, e.g. by writing the User Guide and by performing
helpdesk functions. Researchers, often not familiar with or interested in experimental
software, had to formulate wishes or give judgements on the performances of the tool.
The cooperation between these three groups was not always smooth and miscommunications could not be avoided, in particular because of the short period
allowed for the project.
(2) Although the collaboratories are supported by IISH, it was an absolute
requirement that the pressure on the relatively small ICT department should be
minimal. Therefore, the platforms had to be installed on separate servers. Also, the
members of the collaboratories had to remain outside the IISH system with respect to
login and mail. The administration of the sites had to be performed in principle
entirely by the hub leaders. These demands presuppose a light, browser independent
6
and user friendly platform, in which the rights of users can be set easily by the hub
leaders themselves.
(3) Various collaboratories already had their own website and/or mailing list. This
implied that the hub leaders had to stimulate their colleagues to join the experiment,
while it was not clear that the new platform would definitely replace the old one. In
the meantime, the top priority for the leaders was that the members kept motivated
to contribute to the group’s research activities.
3.2. Workflows
The surveyed groups have all in common that they consist of experts who join to
discuss and build datasets with historical information. However, they display a wide
variety in terms of sources, ways of handling the data from those sources and ways of
cooperating with one another. In this section, we will describe the collaboratories,
with an emphasis on the internal workflows. How is the interaction between the
members – and between the members and the hub ‘leader’ – organized? What are the
actual targets and time frames of the collaboratories? Is there leeway to change the
targets during the project? The following report on the organization and workflows of
the collaboratories involved is based on interviews held in November 2007, at the
start of the Hublab project.
(1) Global collaboratory on labor relations in the period 1500-2000
For the next ten years at least, the IISH is dedicated to pursue the research strategy of
‘Global Labor History’. In this context, the Institute has taken the initiative to make a
worldwide inventory of labor relations at specified intervals in the period 1500-2000.
The project is carried out in cooperation with the Institut für Wirtschafts- und
Sozialgeschichte (WISO) of the University of Vienna. In the project, researchers from
almost all continents joint to merge their data and expertise in order to reconstruct
(the development of) global labor relations. Currently, 22 persons are involved in this
project, that has started on January 1st, 2007 and that will last until April 2009. The
project is supported by NWO Internationalisering Geesteswetenschappen. For this
report, we have interviewed the project leader prof dr Karin Hofmeester (IISH).
Aims. The goal of the project is to create a database in which historical occupational
censuses are ‘translated’ into predefined categories of labor relations. For each
‘sample year’ (1500, 1650, 1800, 1900 en 2000) and for each region/country the
researchers make an estimation of the quantitative importance of particular labour
relations. For what kind of ‘organization’ did people work and what was their position
within that ‘organization’? Thus, what part of the population was not active, what part
worked within households, what part worked for respectively the local community,
non-commercial organizations and commercial organizations? Within each category
a number of groups are distinguished: ‘free’ wage workers, indented labourers, slaves
et cetera. The project director, prof dr Karin Hofmeester, is well aware that the
database will have a temporary character and will contain many missing values.
However, the main purpose of the database is to serve as a first step towards a much
larger international project, for which a grant application will be written after the
completion of the project. Another building block of that application is a parallel
project that investigates labor ideology and labor ethics. It is expected that the
current collaboratory will continue after April 2009 to prepare the grant application.
The website could serve as a permanent platform to present material and to exchange
7
ideas and knowledge on global labor relations as well as ideological notions
concerning labour.
At
the
moment
(November
2007),
the
website
of
the
project
(http://www.iisg.nl/research/labourcollab/index.php) consists of documents (project
description, codebook, list of participants et cetera). The discussion among
participants operates through a malinglist. In a first workshop in Amsterdam (May
2007) the targets were set and working definitions were discussed. The progress of
the project will be discussed at a second workshop in Vienna (March 2008).
Management. The collaboratory is managed by the projectleader, prof dr Karin
Hofmeester. During the interview, she makes it clear that the goals and planning of
the project were pre-defined and are (no longer) open for discussion within the
group. It is her task to monitor and control the planning, however, her means to do so
are rather limited. The participants have all volunteered to cooperate and are not
rewarded financially for their efforts. There are no sanctions for not living up to the
agreements. However, since the goal of this project is perceived as a temporary
product, defaulting of one of a few participants is not considered a serious problem.
Data collection. In order to translate the original source material on occupations into
the agreed format, the participants use a codebook. The codebook was subject of
strong debates at the first workshop and still seems not have found its final form.
Proposals for amendment are put forword throught the mailinglist. In the end,
however, Karin Hofmeester will decide whether and how the codebook is to be
changed. If necessary, changes in datafiles that have already been submitted will be
made at the end of the project. Of course, when an insurmountable problem arises, all
data may have to be changed during the course of the project.
Data submission. The project operates with Filezilla. The participants ‘ftp’ their data
and mail Hofmeester that their data have arrived. She unzips them, checks them and
uploads them in the participant’s directories.
Quality checks and peer review. As said, the members mail their zipped datafiles
(Access) to Karin Hofmeester. She checks whether the material meets the agreed
standards on file structure and annotation. Error-fraught material might be returned.
At this moment, it is not possible to check the content of the data itself. The
participants are seen as ‘the’ experts for their own region. Members are allowed to
look into each others’ subdirectories, but cannot alter anything. Discussion on each
other’s contribution is possible via the mailing list or by direct email. The latter
cannot be viewed by other members nor by the manager.
Documentation. When collaboratory members have additional comments on their
submitted material, they are invited to make these comments in footnotes. When
someone wants or needs to divert from the agreed format or codes, this has to be
documented in a separate file. References to the sources are put in textfiles and will
be collated in a central file
Access to the data after the project. After the end of the project, the data will remain
available only to members of the collaboratory. At least, this is the case for the period
in which the new grant application will be prepared.
(2) History of Work
8
In the social and historical sciences, occupational titles and classifications of
occupational positions are very frequently used to indicate and measure differences
in social class or status. However, these differences are difficult to measure across
great geographical distances or periods in time. On the basis of the occupational title
alone, it is often difficult to say whether a particular job entailed supervisory tasks, or
whether a job was salaried or self-employed. Therefore, it is difficult to employ
historical occupational titles in internationally comparative research. To make
worldwide comparisons of labour relations, social stratification, social mobility and a
host of other social phenomena, a harmonization of titles is a necessary precondition.
A very influential effort in that direction is made by the ‘History of Work Information
System’. This hub functions as the central meeting places of researchers who work
with (historical) titles and is also serving as the virtual repository of their datasets.
The website (http://historyofwork.iisg.nl/) contains occupational titles from all
countries and periods, standardized codes for the professional activities (HISCO, a
historical version of ISCO, which is developed by the International Labour
Organisation) and images of all forms of labour. At the moment, the coded titles
pertain mainly to Western Europe and North America, but the interest from Asia,
Latin America and Russia is growing and researchers from these areas are starting to
contribute to the ‘hub’. For this report, we have interviewed the project leader prof dr
Marco van Leeuwen (IISH and University of Utrecht) and drs Richard Zijdeman
(PhD student UU).
Aims. The History of Work ‘hub’ is the result of a long standing (more than fifteen
years) cooperation between professor Van Leeuwen and various other experts. In this
cooperation, the experts systematically and cumulatively build a central coding
system of all occupational titles in the world. The project can be termed ‘finished’
once all titles are coded and the codes are available to the research community via a
(semi-) automatic coding system. This user-interface is already available for various
countries and languages. For some countries, the work is nearly finished, but in
others it has not even begun properly. The occupational codes are themselves the
condition and crucial means to arrive at an internationally accepted schemes of
historical class and status (respectively HISCLASS and HISCAM). The work on the
status stratification HISCAM is being financed by research grants (VIDI and NWOInternationalisering), that will expire in about a year. However, the targeted scheme
has already been developed. Apart from coding and classifying titles, the project
group collects images of historical activities and descriptions of all forms of work in
the past. In a sense, the website serves as a museum and library of historical
occupations.
Management. Prof Van Leeuwen has the task to control the project, in terms of
targets and planning. However, this role has to be put into perspective since
participation is voluntary and pressure on people may work counterproductive. In his
view, it is therefore not always wise to bother people with intermediate goals and time
schedules. He sees his task as directing the field towards filling up existing lacunae.
This is complicated further by the fact that there exists no complete overview of the
extent of work still to be done. These exists no complete inventory of all sources
containing occupational titles in the world. In running the project, Van Leeuwen
works closely with Dr Maas (UU) and drs Zijdeman (UU). The project leans rather
heavily on their personal commitment, also in the sense that continuity in the future
9
is not (yet) institutionally secured. On the other hand, the IISH has committed itself
to continued support of the facility.
Datacollection. There is no clearly circumscribed group of participants in this project.
Generally, experts are being invited via mail or call for papers for conferences or
edited volumes to code the occupationals titles in their region on the basis of the
HISCO codebook or the online semi-automatic coding system. Apart from that, the
project leader(s) offer their assistance, by giving advice and/or checking the
submitted datasets. Actually, the mail address on the site is linked to Van Leeuwen’s
personal address, which means that in practice all correspondence goes through his
hands.
Data submission. The website is not very clear on how to submit datasets. In
principle, Excel files are preferred, but the data tend to arrive in different formats
that have to be converted by hand. Also, the number of records is stretching the limits
of Excel. The data are all submitted through email. The Excel-sheets are eventually
exported to a MySQL Database.
Quality checks and peer review. The submitted datafiles are visually checked by Van
Leeuwen, Maas en Zijdeman on the correct application of HISCO codes and where
necessary corrected. In case of doubt, they reach consent among themselves on how
to deal with specific issues. They would welcome a form of automatisation of this
procedure, as well as making it more a collective concern (via a peer review system).
Currently, there is a considerable backlog of foreign datasets to be processed. Most
ideal would be an automatic coding system that links the data in submitted files to the
central database and returns them with the correct HISCO codes. As for peerreviewing: it is possible to attach the name of a given expert permanently to his/her
coded titles in the central database. This will enable a more efficient control and
possible change of titles coded by these experts. However, this might also discourage
persons to participate. Currently, direct peer review is not possible. However, the link
with the original datasets is preserved and thus it is known who was responsible for
the coding. These original (Excel) files cannot be downloaded.
The HISCO coding itself is no (longer) subject to intense debate, contrary to the
extension of the project into global class and status-schemes. Generally, discussions
on coding have to do with differences in the interpretation of work by locality and
period. Although the project leaders welcome such discussions, they are also
reluctant to contextualise occupational codes (that is, make them place and period
specific), as that would diminish the value of HISCO, HISCLASS and HISCAM as
tools for comparative research. In the future, they do not expect drastic alterations in
the codes, which would imply changing the central database. The discussion on the
codes is all done through mail and is not visible for others.
Documentation. A detailed description of the sources is not required of researchers
who submit datafiles, but personal information and institutional affiliation is
generally provided. The credits for offering data are given in the field ‘provenance’,
and there is also a provenance section on the site. Remarks and other references to
the data are integrated in the database and can be retrieved per record.
(3) Towards a global history of life courses. Creating a network for the development
of data structures for standardized longitudinal historical data
10
This collaboratory is being constructed in the context of an NWO
Internationaliseringsubsidie and is headed by Dr Kees Mandemakers (IISH). In this
international project, the managers of large databases in the field of historical
demography will develop a standard data model (both online and in workshops) for
longitudinal micro-demographic data with the aim of converting data from the
different databases into an interoperable file structure. Such a structure would
enhance the access and dissemination of the databases in question strongly, in
particular by allowing for international comparative research. Also, simplified
datastructures directed at specific fields of research will facilitate demonstration and
will increase the use by a new generation of researchers. The project runs from
January
2008
June
2009
(see
http://www.nwo.nl/projecten.nsf/pages/2300139638). The project is initiated by Dr
Mandemakers (Historical Sample of the Netherlands) in close cooperation with Prof
dr George Alter (Interuniversity Consortium for Political and Social Research, Ann
Arbor, USA) en Prof dr Anders Brandström (Demographic Database Umea, Zweden).
Their organizations contribute financially to the project. In fact, these three ‘leaders’
have set the main targets of the project, which is not open to further discussion in the
group at large. At the moment working documents are prepared to form the basis for
a workshop to be held at the 1st and 2nd of May 2008 in Ann Arbor which will be
attended by a core group of six important databases (from Europe, Japan and
Canada) A follow up conference with more participants will be at 22th of October
2008 in Miami.
Aims. In the first stage of the project (January-March 2008), the initiative will be
made known to as many experts in this field as possible. People will be invited to join
the discussion group. In fact, already a lot of contacts with databases around the
world exist, since the project continues along the lines discussed in an earlier
workshop (March 2006). Subsequently, the project will work step by step towards an
ideal ‘intermediate structure’, by discussion drafts in workshops and in a discussion
list. The aim is to reach a consensus on a document describing a data model in which
one can upload selected information from the separate databases and that
restructures the complex dynamic information on individual life courses into a range
of relatively simple, comparable and well documented formats depending on the
research fields. Also, the project aims to collaborate in the writing of a grant proposal
to construct the software and documentation that implements the functional design
and data model laid out in the joint document.
The project will not assemble or disseminate data, but aims to remove the technical
reasons for not making complex longitudinal data publicly available in a comparative
way.
The website of the collaboratory will be part of the IISH ‘cluster’ of sites, but will also
be placed in the more neutral environment of the International Commission for
Historical Demography (http://historicaldemography.net/). Actually, this site is
managed by Mandemakers and IISH as well. In the process, this public site will be
given more content and will hopefully attract more visitors. At this point, it is not
clear whether and how functionalities of the collaboratory platform can also be used
for this public site.
(4) Labour conflicts
11
This collaboratory is (like the one on Labour Relations) part of the IISH research
strategy of Global Labor History. In this case, the aim is to construct a standardized
collection of labour conflicts (strikes and lockouts). Labour unrest forms a good
indicator of tensions created by specific labour relations as well as their interaction
with conjunctural trends and societal developments. Already, the IISH has a database
containing standardized information on 16.000 Dutch strikes in the period 13722006. The structure of this database will serve as the model to be adopted by the
collaboratory. This standard (based on the format of the International Labour
Organization) includes the number of workers involved in a specific action, the
duration of the action, the amount of hours/days not-worked, the number of
companies involved, the involvement of labor organizations, the demands of the
strikers, and coding according to international standards of occupational groups and
economic sector involved. Dr Sjaak van der Velden is the leader of this project, which
runs from October 1st, 2007 until October 1st, 2009. The project is sponsored by
KNAW (project Global hubs for global history). For this report, we have interviewed
Dr Van der Velden.
Aims. Dr Van der Velden hopes to create a website that will function as the central
place for information and discussion on labor conflicts, and also as the central
repository for the standardized dataset. Clearly, he is not in a position to enforce the
standard for the intended dataset. In other words, if researchers offer their material
in another format, he will not refuse them. Also, since this is an effort to bring
together people on a voluntary basis, it is not feasible to make a detailed planning
with subtargets et cetera, let alone put sanctions on non-compliance. Basically, Van
der Velden is trying to motivate researchers in this field to join the project and to
meet in the spring at a workshop where the idea can be worked out in more detail.
Only then will it become clear if the group is motivated and able to work on a joint
task such as a publication or grant application. So far, the interest in the project is
encouraging. Already about 40 researchers have indicated their interest in this
initiative.
Datacollection. In the first stage of the project, Van der Velden wants to focus the
group on discussing the proposed codebook. This will be done through the mail and
through the discussion platform and will be completed at the targeted workshop (May
2008). Possibly, the codebook will have to be redefined in a later stage, but obviously,
Van der Velden hopes to avoid this.
Data submission. The data format proposed by Van der Velden is rather elaborate
and possibly too detailed for many countries. Again, he does not want to put up any
thresholds by demanding a specific format. Thus, he feels that other formats should
be allowed as well and sees as example the hub on Prices and Wages
(http://www.iisg.nl/hpw/) in which many Excel files are collected that differ strongly
in structure. Currently, the files are submitted in Excel, but will probably be
converted to a central relational database. It is not yet clear whether online data
entrance should be enabled.
Quality checks and peer review. Van der Velde will check the data and (probably)
convert them into the central file. However, it is not possible for him to check the
content of the submitted material. He aims to allow group-wide inspection of the
individual (and named) files. He supports discussion in the group but in the
12
meantime fears for a cluttered whole. The moderator will have to decide what shall
open for discussion and what not.
Documentation. Van der Velden expects that each participant at least provides
references to the sources and describes how the strikes were collected.
Access to the data. At this moment, the continuation of the project after October
2009 is unclear. If the group finds this necessary (e.g. for joint publications or grant
applications), a temporary embargo may be laid on the assembled data.
Common to all four groups seems to be the lack of clearly specified workflows,
corresponding to the voluntary nature of the member’s contributions. Expectations
regarding member’s contributions are most explicit within the group on Labour
relations. In the next sections we report on the functionalities that the project leaders
found more or less desirable for their ‘hubs’.
3.3. Desired functionalities
Apart from internal organization and workflow, the interview with the hub leaders
focused on functionalities in a virtual research environment. The interview followed a
set of questions specified in Appendix 1. The answers for each collaboratory are
stored in the file ‘scorecard.xls’. Functionalities deemed important by most of the
leaders were:
1) the platform should be web-based, with guaranteed continuity
2) flexible setting of a variety of user rights by hub administrators
3) activities of users have to be visible in logs
4) a division on the site between a public and private part
5) integration with existing mailserver accounts
6) a webforum
7) a clear and flexible structure of directories
8) facilities for different data formats
9) version management
10) facilities for adding metadata, preferably automatic
11) flexible interface, to be adapted by users at wish
12) search options, both on metadata and content
13) users can change their own passwords
The following functionalities were considered less important:
1) user statistics
2) support for audio and video-conferencing
3) wikis
4) shared calendar
5) (automatic) visibility of individual contributions to joint datasets
6) interface in different languages
Finally, unimportant or even undesirable were:
1) importing or exporting data in xml format
2) registration of users of the public site; guestbook
3) instant messaging
4) online whiteboards
5) to-do lists and automatic alerts
13
6) synchronization of calendars with PDA’s
7) publication of blogs
8) online manipulation of data with plug-ins for SPSS and other programs
9) incorporation of RSS feeds
10) integration with search systems (Google, Picarta etc)
11) tagging metadata
12) security devices, such as encryption
The priorities reflect the voluntary character of most collaboratories. Functionalities
that may improve a workflow (to-do lists, integration with PDA’s), probably do not
match the egalitarian character of these groups. In addition, several hub leaders are
wary of ‘high tech’ solutions given their own dexterity (or lack of it) and their
expectations regarding their members. However, for the Guilds group that joined the
pilot project in January 2008, sophisticated functionalities such as online
manipulation of a central database and integrated mail were highly important.
4. Comparing collaborative software
In the comparison of Sharepoint, Sakai and Liferay by ICT-staff two sets of issues
were crucial. First, to what extent does the software meet the requirements indicated
by the collaboratory leaders. Second, what does the platform imply for the ICTdepartment itself: how quickly can it be installed, how efficient is the support by the
user community or the company providing the program, what is the fit between the
software and the experience and knowledge of developers at the Institute? In
Appendix 2 the results of the ICT-test are presented (in Dutch). Here, we can only
briefly summarize the outcomes.
Sakai was seen as a user-friendly, simple program. However, its use for collaborative
purposes seemed limited, probably because it was designed for the interaction
between teachers and students. This implies that a number of functionalities would
have to developed. However, this is not supported by the creators of the software. In
case of upgrading, no guarantee is given that newly developed applications will still
function. In addition, Sakai has a relatively small community of developers and users
working on improving and developing the product. The first release was in 2005 and
although, for instance, whiteboards and blogs are added, the main target seems to be
the educational sector. Adding functionalities would imply a heavy investment from
the Institute’s ICT en DI departments, and would also require sustaining the
knowledge of specific programming languages. As many developers at the Institute
work on temporary contracts, this cannot be guaranteed. The alternative, a detailed
documentation for developers, is very time-consuming. In this case, the costs to
ensure the stability and safety of the program after adding patches are relatively high.
Renewed ‘building’ and testing of the package takes too much time.
Sharepoint proved to be the most complete environment with guaranteed support
and patches. It looks familiar for people used to Microsoft products. Support and
patches are guaranteed, and making new web-parts with via ‘Sharepoint designer’ is
unproblematic. However, adding additional functionality to existing Sharepoint webparts is not possible. The program would tax the ICT capacities within the Institute
heavily, it would take a long time to implement, and heavy training for administrators
would be necessary. Finally, the vendor lock-in is mentioned as a problem.
14
The open-source package Liferay was considered easy to implement, with sufficient
support from the extended Liferay community, easy to manage by the collaboratory
administrators and with sufficient options to store and share data. The Java ‘engine’
makes is possible to run Liferay on several operating platforms draaien. The Service
Oriented Architecture makes it easy to build and add new functionalities. Already,
many plug-ins are available. During the test period, it was not possible to insoect
Liferay’s performance when combined with the open source content management
system Alfresco, Apparently, the announced cooperation between both is still in a
preliminary stage. Nevertheless, Liferay in itself met already most of the
requirements specified by the users and the ICT department and it was therefore
decided to build the pilot environment on this system.
5. Installation and test of Liferay
The hub leaders users had specified their preferences for a platform with flexible
rights management; a webforum; good directory structure for data, documents and
discussions; version management; storing of metadata, preferably automatic,
visibility of intellectual property of data and proper search facilities. An integration
with existing mail system was also mentioned. For a single group (Guilds) tracking of
changes within datasets and online work on a central database was a high priority. In
retrospect, these wishes can be distinguished in two groups:
1) Wishes that could be implemented easily: rights management, simple directory
structure, webforum, version control and search facilities
2) Wishes that proved beyond the budget, the technical options of Liferay, or the
period allowed for this pilot: visibility of intellectual property; online adding to
datasets; tracking changes in datasets; integration with email and automatic storage
of metadata.
In principle, the latter functionalities could be developed in due course. However, to
some extent these wishes reflect a lack of knowledge of web-based environments as
well as unfounded expectations with respect to collaboratory members’ use of the
platform. Thus, further enrichment of the platform would require a renewed
inventory of the collaboratory leaders wishes.
An integral part of the installation of the test platform was the production of a User’s
Guide, added to this document as Appendix 3. The illustration below shows the portal
of the collaboratory site. One can visit each collaboratory’s public pages, or one can
login as a member and visit the private pages of the sites.
15
Liferay turned out not to be without problems of its own. A first serious problem was
that the platform did not function on a proxy-server, which was considered necessary
to guarantee security. This problem, that could be fixed rather easily, frustrated the
demonstrations planned by two groups at an international conference in late
February 2008. The second ‘bug’, in version 4.4.2.of Liferay, implied that internal
links were confused when new pages were added. Therefore, several administrators
were hesitant to organize their sites and waited until the problem was solved with the
release of version 5.0.1. Clearly, this limited the period in which the environments
could be tested even further.
Appendix 4 offers a more detailed, technical description of the installation, support
and maintenance requirements of Liferay (in Dutch).
6. User experience of Liferay
Due to minor problems in the ICT department and the server problem mentioned
above (see also section 8), the proper installation of the environment by the
administrators started early March. Some groups waited until the release of version
5.0.1 in early April. All in all, the several delays resulted in the fact that the platforms
were hardly tested in the proper research environment. The general forum that
allowed reporting and discussion on bugs and new features was used quite intensively
for some time. In fact, a large number of the problems that were mentioned here were
solved during the pilot project. Integration with existing mail systems, however,
turned out to be too costly.
Responses to the questionnaire
16
In May, we sent out a questionnaire to make an inventory of the user experience with
Liferay (Appendix 5). The forms that were filled in and returned make it clear that
feedback from the users was not (yet) available. Thus, the experience described and
analyzed in this section is based on the administrators’ comments only.
Question 1 of the questionnaire related to Adding new members to the groups.
‘Currently, members are admitted first on the general list of users of the portal. Either
they can do this themselves or the administrators sign them on. Subsequently, they
can request permission to join a collaboratory, or the administrator can do so
beforehand.’
In general, the administrators indicated satisfaction with the functionality, in
particular the ability to define roles, although complaints were voiced with respect to
not being able to change user data. It was also suggested that the system should
‘recognize’ registered users, making requests to join a second collaboratory more
simple. Finally, the notifications of requests to join a group are presently very
confusing.
Question 2a was related to general Functionality with respect to rights. ‘The default
rights structure is as follows: administrators have all rights on all files as well as all
portlets. The members, on the other hand, can only modify or remove their own files.
They can only add new structures to folder and forums within the settings created by
the administrators.’
This system was definitely appreciated, in particular the possibility to change these
defaults when required.
Question 2b specified : ‘Administrators can change the default rights (view, downand upload) of the members. This goes via update associations /update permissions,
but it has to be done for each folder or document separately’.
In this respect, the users requested a more generic solution, by changing the role of
users.
Question 2c: ‘Users of the private pages of the platform can only set rights on their
own documents or folders.’
According to the administrators, this is how it should be done.
Question 3 went into Document management: ‘Liferay allows you to create folders, to
up- and dowload files, documents and images, to make annotations and to manage
versions.’
One administrator had good experiences with making separate folders for each
member, which allowed for setting rights for these members simultaneously. Version
management was considered very handy. Up- and downloading of data proves
efficient. Problems mentioned had to do with browsers – not everything worked
properly in Firefox. Also, someone mentioned that adding metadata directly to
images is not possible; the metadata are stored in a separate directory.
Question 4 was related to Search facilities: ‘In the Liferay platform, we have installed
several search functionalities: On (text in) documents, on (content of) messages, on
users. Do they meet your requirements?’
Most of the respondents admitted to not having tested this facility and one of them
had noted that they did not function properly: search results did not match the
searched items. One respondent was pleased with the option to add tags to messages,
which increased the search functionality.
17
Question 5 dealt with Metadata: ‘Relatively few metadata are attached to documents
and files: document name, version, size, and file format. Are you satisfied with this
functionality or should it be extended?’
Most of the administrators haven’t used it. One commented on the unsatisfactory
integration with version management. Versions are only visible after clicking
“actions”, view / edit. Not all versions are visible. And when someone oploads a
wrong version en removes it, all version of all files are removed, including all
comments.
Question 6 was on communication: ‘Because integration with the email system is
currently not possible, communication, and to some extent out-bound mail as well,
operates through the forum and the option to comments on separate pages. What is
your opinion on these options?’
This essential element of the platform was not appreciated by the hub leaders. Most
of them still use email or mailing lists and do not see the (subscription of users to) a
forum as a proper alternative.
Question 7 pertained to the calendar: On the page ‘events’ a calendar has been
installed. Is this useful?
Some administrators saw no use for this tool, whereas others pledged for a longer
time period to be shown (currently, if focuses on the present day). One administrator
hoped that people would be able to subscribe to the calendar, and integrate it into
their outlook/icalender/sunbird/google calendars.
Question 8 had to do with Content management of the website: ‘As administrators
you can extend your own webpages, change the content, add images and links et
cetera’.
This functionality was appreciated, although some complain about its limited userfriendliness. A more experienced user noted that it functions much better than in
many other CMS’s.
Question 9 dealt with General functionality: ‘The platforms allows you to add new
portlets. Have you done this? Have you missed specific functionality during the actual
test? ‘
Most administrators mentioned here the lack of an integrated mail functionality. One
administrator has added the option to post comments directly on each specific page
of the platform.
Question 10 was on Ease of use: ‘An important criterion for the choice of a platform
has been ease of use: clear buttons, intuitive design of the site, good explanation
where necessary. In short: the ‘look and feel’.
Most administrators were not positive with respect to the ‘look and feel’. They
mention strange names and unexpected functions for buttons, difficulties with
creating navigation links and menus in the left-hand part of the screens. One user,
however, is very satisfied with the freedom to design the portal, add portlets at will et
cetera.
Finally, question 11 was about the ‘Helpdesk’: ‘Frans and Lucien are subscribers to
the category Guest>private pages>make feature request and report bugs in order to
respond to questions and problems. Has this worked well and should it be continued?
18
A user guide can be found on the messageboard. Is the guide satisfactory? What
points deserve more attention?’
In general the service provided was considered very helpful. The user manual should
be extended and updated with respect to the setting of rights, creating menus and
customizing navigation. One administrator thought the guide should be
supplemented by videos demonstrating how to perform certain tasks.
Interpretation
How can we evaluate the ‘success’ of this pilot? The first goal, to create a workable
virtual research environment, has certainly been achieved. The second goal, to make
this environment into the lively meeting place and virtual laboratory of peers, is
proving more difficult to reach. As said, ordinary users have hardly used or been able
to use the platform, apart from the members of Labor Relations. Most administrators
admit that their members haven’t used the facilities, but they differ strongly in their
expectations on future use. Most of them seem willing to put more energy in urging
members to use the site, particularly when facilities such as email (both in- and
outbound) are added. Others however feel that this platform has no added value to
what they already offer: a site with downloadable data and a mailing list. One leader
claims that the momentum to motivate members was lost when the live
demonstration failed.
To understand these different reactions, we have to taken into account some of the
institutional factors discussed in section 3. Firstly, the hub leaders themselves have
become involved into the project in various ways. Some of them have been urged
rather strongly to join the pilot, although they saw relatively few merits from the
onset (Labour conflicts). Others, on the other hand, had high expectations from the
collaborative software, which could not always be realized within the pilot (Guilds).
Clearly, the level of motivation of the leader has impact on how he/she designed the
platform and, most important, stimulated members to use the environment.
Secondly, some of the collaboratories exist already for some time (in the case of
History of Work/HISCO many years), others are new. In the case of new
collaboratories, leaders may be hesitant to expose their group to ‘experiments’, which
may weaken their own credibility and position. On the other hand, leaders of settled
groups need to motivate their group to change their routines.
Thirdly, it can be assumed that when workflows (of data to be inspected, or
documents to be discussed) are more important for the working of a group, the more
important a platform can be for the group. Functions such a repository for data and
documents or a mere platform for exchanging ideas seem insufficient to motivate
members of a research team to participate intensely.
Finally, the success of the platform seems to depend to some extent on life
demonstrations. The planned demonstrations for HisWork and Guilds of the Liferay
tools in Lisbon in February 2008 failed due to the bug we already mentioned.
Successful demonstrations were held in March in Vienna (Labour Relations) and end
of April in Ann Arbor (Life Courses). The Labour Conflicts collaboratory will meet in
August for the first time. In the schedule below some of these aspects are
summarized. Again, the ‘success’ of the platform in terms of intensive use by the
groups cannot be determined at this stage. The final column indicates the present
(June 2008) situation of the Liferay platform, after having been operative for two
months.
19
Collaboratory
Labour
relations
HISCO
Life Courses
Labour
conflicts
Guilds
Motivation
leader
High
‘Workflow’
Yes
Age
collaboratory
One year
‘Life’
demonstration
Yes
Platform
succesful
Reasonably
High
Average
Low
Yes
No
No
>10 years
New
New
No
Yes
No
No
Potential
No
Average
No
New
No
No
7. Lessons learned and prospects for future research
What can we learn from this short-term pilot of collaborative software to be tested by
researchers in their daily work?
1) Firstly, the pilot has demonstrated that communication between researchers and
IT developers demands more time and attention than anticipated. Researchers
(perhaps particularly in the humanities) tend to have unrealistic expectations of
applications, with respect to what they can achieve and the time in which they can be
developed. Conversely, developers (perhaps particularly those with a commercial
background) have difficulty to grasp the labor division within collaboratories.
Working groups of researchers are based on mutual trust and voluntariness. Tools
that may function well to speed up productivity within companies (workflow
management, integrated calendars) may have a contrary effect on collaboratories, as
they suggest a hierarchy of functions and lack of trust in timely contributions.
2) Secondly, although Liferay was specifically selected for its user-friendliness, even
the most motivated administrators became disheartened when navigation turned out
to be cumbersome, button labels were unclear, setting of rights was somewhat
complex, online Content Management proved more difficult than what one was used
to et cetera. In short, the product was not immediately attractive and intuitive.
Although most of these problems could be solved within the pilot project, a number
of leaders became hesitant to promote Liferay in their groups, although in practice
common members did not experience most of these problems which are related to the
administrator’s tasks. We can only conclude that more time and energy should have
been spent to make the Liferay platform more intuitively appealing for the user.
3) Life demonstrations seem vital for the acceptance of the platform, but they failed
in a number of groups, for several reasons. Obviously, the budget did not allow us to
convene these international groups specifically to demonstrate the platform.
Therefore, the demonstrations were planned to coincide with already organized
meetings, but this was not always possible. Apparently, the user guide in itself did not
stimulate enough to try out the program. As an alternative we are now thinking of
making video demonstrations for users with different roles. In fact, one of our
administrators has already made such a demonstration for the task ‘adding events to
the calendar’.
4) As a general conclusion we can say that (new) collaboratories (in the humanities)
seem to be a rather vulnerable environment for testing new software, in particular in
such a short period. Furthermore, scientific group activities cannot be ‘rushed’, each
group has its own planning of activities and pace of work which cannot be changed
20
for a pilot project. However, it has to be admitted that the pilot project functioned in
a sense as a ‘pressure cooker’, speeding up processes and decisions that otherwise
may have been stalled.
The project has resulted in two kinds of knowledge. First, we have gained technical
expertise on collaborative software, not only by installing and improving the Liferay
package but by learning from the other groups in the SURF tender as well. For the
time being, the groups will continue using Liferay. In fact, a new group has been
added recently, a collaboratory on Migrant Organizations. Probably, a definite
decision regarding the continuation of this platform will be taken in the final stage of
the Global hubs project (December 2009). Second, we have gained a better
understanding of the interaction between the dynamics of research teams and the
(potential) role of communication software. This will help us to implement IISH’s
strategy to support and create data-hubs based on collaborative research. One
example of this is the European project CLIO-INFRA (www.clio-infra.eu). Secondly,
this kind of knowledge is integral to the KNAW research project ‘Socio-technological
aspects of cooperative research in social and economic history’ (S. Dormans). This
project aims to determine ’best practices’ in history, but with relevance for research in
the much wider field of the humanities. Dissemination of these two kinds of
knowledge is foreseen in several ways. In the field of history, several presentations
(a.o. a session on the 15th World Economic History Congress inUtrecht 3-7 august
2009) and publications are planned. In the field of e-science, already several
demonstrations and presentations are planned: at the summer school in Amsterdam
of the University of Washington (august 2008), the joint EASST and 4s conference,
August 2008 Rotterdam and the Oxford e-Research conference (September 2008).
Finally, pending a decision on the continuation with Liferay, the proposed webpage
describing HubLab activities will be created.
For the IISH, future research on collaborative platforms – possibly within the context
of a new SURF tender-project will have to match the specific characteristics of our
research as well as to address key issues discussed in this report. With respect to the
first, all issues concerning data-sharing are of interest to us. How is intellectual
property of data to be understood, how can it be made visible? What kind of license
structure matches on the one hand the way data are gathered within collaboratories,
and on the other hand the way in which upgraded data are made available to the
wider public? How useful are the Creative Commons licenses in this respect? How
can the software support clear documentation, annotation and version control of
shared datasets? With respect to the latter, we need more research into user
motivation to make use of collaborative tools: to what extent is integrated email
necessary and possible, what is the added value of demonstration videos, what makes
a product immediately appealing to lay users?
21
8. Project evaluation and financial report
Planned and realized deliverables
In this section we recall and evaluate the original planning of the project as outlined
in the controlling document. In the first stage, the project went ahead as planned.
Deliverable 1, The inventory of workflows and desired platform functionalities of the
‘hub’ leaders was ready by late November 2007 as planned, and has been put on the
Surftender site
https://www.surfgroepen.nl/sites/surfshare/tender2007/Hublab%20IISG/Forms/D
etailed%20View.aspx as scorecard Def.xls and Designing a platform for
collaboratories.pdf (Jan Kok and Frans de Liagre Böhl).
Planned deliverables and time table.
WP1
WP2
WP3
WP4
WP5
WP6
Nov
2007
D1.
Dec
2007
Jan
2008
Feb
2008
Mar
2008
April
2008
May
2008
TEST
TEST
TEST
D.4
D.5
June
2008
D2.
D3.
D.6
D.6
The second stage was the test of by ICT-staff of the relative merits of Sakai,
Sharepoint and Liferay in terms of technical specifications, anticipated learning curve
for administrators and users, open source versus company based, and matching with
the requests of the hub leaders. This test was completed by Mid-December, ahead of
the planning. Deliverable 2 was presented in the form of an excel sheet (technische
test.xls), summarized in the Technische Rapportage Hublab project.pdf (see the Surf
tender site of Hublab and Appendix 2).
In early January, the selected platform Liferay was installed for five test sites, on the
basis of an (internal) configuration management procedure (WP3). However, due to
overburdening of the ICT department and the pressure caused by an international
application for the collaboratory project (see www.clio-infra.eu), WP 3 was delayed
with several weeks. However, in addition to the original plan, a user guide
‘Collaboratory portal IISH User Guide’ was produced by Frans de Liagre Böhl (see
Appendix 3). Deliverable 3, the actual test platform, was ready by late February.
The actual test of Liferay took place from March-May 2008. As mentioned earlier, an
error in Liferay frustrated logging-in from outside the institute, which made it
impossible to demonstrate the platform as planned by several collaboratories at the
European Social Science History Conference, 26 February-1 March 2008 in Lisbon.
Successful demonstrations were held in Vienna March 2008 and Ann Arbor (USA) in
April 2008. Some further delay, however, was caused by a second software problem
that confused links to added pages in Liferay.
Deliverable 4, the inventory of user experiences (based on the questionnaire in
Appendix 5) was completed in early June, and discussed at the SURF tender meeting
22
on June 17th (see presentatieSURF3.ppt on the site). The findings have been
summarized in section 6 of this report.
Deliverable 5, a website of webpages introducing the project has not been realized yet,
pending the internal evaluation of Liferay as a tools for the Institute’s collaboratories.
However, the Liferay platform (https://collab.iisg.nl) has extensive public pages for
guests which function as an introduction to the project.
Finally, Deliverable 6, an interim and final report by the project leader, were
produced according to plan.
Financial report
In the controlling document we have specified the anticipated workload per person
for each Work Package. Obviously, in the course of the project all kinds of changes
occurred, e.g. in terms of personnel involved. As the contribution of the Guild’s
project (TDM, Tine de Moor) was not included in the controlling document, we leave
it outside the financial Eindtotaal. The same applies to the contribution of drs
Zijdeman who has done much work for the HISCO site.
Original budget
We will describe here the most important changes and adaptations with respect to the
original plan. What we see is that the input in hours from the hub leaders (KMA, SVV,
MVL and KHO) was less than anticipated. This has to do with the fact that they had
less time to actually experiment with the platform and to discuss findings with their
23
members than planned, due to delays described in previous sections. The technical
problems encountered in the beginning resulted in much more input from the ICT
department (MMI: 155 versus 57) than expected. Installing the platform for five
collaboratories, producing a user manual, answering questions and reports, and
developing improvements for the interface meant a huge increase in hours for staff
members of Digital Infrastructures (FLB 210 versus 120 hours and LVW 127 versus
80 hours). In fact, to support this crucial element of the project and to keep the
budget within limits, the decision was made to find alternative funding for travels to
international collaboratory meetings. Finally, the overall management by the project
leader was slightly more than planned (178 vs 158 hours). In his case, the work
continued well into June (preparing for the SURF meeting June 17th and writing the
final report).
Final financial report
Totalen
p/p
FLB
JKO
MMI
OKE
GCU
LVW
KHO
SVV
MLE
KMA
TWE
JEG
RBE
JIB
RZI
TdM
Totaal
gepland
120
158
57
49
49
80
95
91
91
91
4
4
889
Gemaakte uren tot 1.7.08
210,25
40
11353,5
178
52
11748
154,75
40
8356,5
34
32
1564
35
32
1610
127
37
6477
50
52
3300
31
46
1860
66
52
4356
39,5
56
2765
8
60
592
5
56
350
3 41,65
166,95
32
32
1472
56
32
2576
10
50
500
1039,5
59046,95
kosten schrijven aanvraag hierbuiten gehouden
reiskosten
247
hardware
5427
totaal
Eindtotaal
64720,95
61644,95
24
9. Conclusions
A short experiment with new communication software in an environment of
emerging collaboratories in the humanities is not without risks. One the one hand, in
the short period in which the test has to take place simply too little interaction
between groups members may to test the product properly. One the other hand, the
tool may not have reached a stage in its production to motivate and stimulate
researchers to work with it. In the case of Hublab, both problems occurred to some
extent. However, the effect was mitigated because we had installed platforms in no les
than five colaboratories, ensuring that, overall, the software was tested on most of its
functionalities. Moreover, although the learning curve for the Liferay tool for
administrators (hub leaders) was steeper than anticipated, it seems without problems
for common members of collaboratories. The latter, however, still awaits further
tests.
Having different collaboratories working with the tool allowed us to connect the
different institutional settings, workflows and group dynamics with the reception of
the Liferay tool. Which groups are more motivated than others and why is that?
Although the voluntariness of all collaborative research has to be emphasized
strongly, some groups have a more explicit workflow than others. Also, life
demonstrations seem a crucial precondition for a successful implementation. We will
continue this line of research in the context of Stefan Dorman’s project ‘Sociotechnological aspects of cooperative research in social and economic history’ (Virtual
Knowledge Studio).
Further efforts to improve the platform will concentrate on three topics. First, further
improvement of the ‘look and feel’, e.g. by adding demonstration videos, better
navigation, make button labels unequivocal et cetera. Second, improvement of
communication functionalities, in particular integration with email. Last, working on
various aspects related to data-sharing: version management, a licence structure,
intellectual property right and possibly online manipulation of data.
25
Appendix 1. Interview on current workflows and desired
functionalities of the collaboratory platform.
In the interviews, the first part was devoted to gaining insight in the aims, planning, current
practices of the collaboratories, and expectations regarding cooperation and communication.
The questions involved are subsumed under A. In the second part, more specific questions
regarding functionalities of supporting software were raised (B).
1. WORKFLOWS
1. 1 management
Aims
1. What is the final aim of the project?
2. What is the planning in terms of intermediate goals?
3. Can these intermediate goals be modified in discussion with the participants?
4. Is there leeway vis-à-vis the sponsors to modify the project’s targets during the project?
Planning
5. Is there a specific planning?
6. Who monitors the planning?
7. Is it possible to change the planning in discussion with the participants?
8. Is it possible to discuss change of planning with eventual sponsors? Is the planning tied to
a calendar?
9. Are there sanctions for not reaching (intermediate) goals in time?
Quality and progress control
How is the quality of the results assessed (by peer reviewing or only through a central
evaluation of the input?
10. Who monitors progress and how? Are there sanctions for not observing agreements? 11.
What happens once the central goal has been achieved: are all results made public, or only
specific results? Are the data placed under an embargo?
12. Who manages the final results? Does one anticipate permanent supplementing and
correcting of data and how is that to be conducted?
1. 2 Handling individual data
1. Does one work with a central codebook to build the final product and is this codebook
the subject of internal discussion?
a. If so, is that discussion limited to a specific period?
b. How is that discussion organized, who collects and assesses the input?
c. How is the synthesizing conclusion communicated to the participants?
d. If the codebook were to change during the course of the project, does this
imply that already collected data will have to undergo changes as well?
2. If there is no codebook, how is the cohesion between the data submitted to the hub
guaranteed?
1.3 Building the central database
1. How do the contributors actually submit data?
26
2.
3.
4.
5.
6.
7.
How are the individual contribution imported into the central database?
Who manages the central database?
Can all members inspect each others contributions (immediately)?
When and how is it possible to comment on each others contributions?
Is that internal discussion visible to outsiders as well?
How is central control of the contributions organized? By checking for compliance to
the codebook, by checking for internal consistency, are there procedures for finding
errors? Is it possible to locate missing data?
8. How is the feedback to the contributors organized?
9. If the data seem not fit to be put into the central database (see 7), who will
correct/modify them?
1.4 Producing documentation
1. What is expected of individual contributions with regard to references to source
material, explanation of procedures (if diverging from joint procedures), estimation
methods (if diverging from agreed methods), interpretation et cetera?
2. Are those remarks integrated in the database or submitted in separate text files?
3. Are the remarks summarized in central texts?
2. Expectations regarding the collaboratory platform
Indicate the desirability of each functionality on a scale of 1) not particularly important to 3)
indispensable.
A General
1. The environment has to be webbased, that is, only a computer with access to the internet
and a browser are needed to gain access to the collaboratory platform.
2. The platform has to allow for developing simple applications or modules within the
community environment. Thus, RAD/Scripting has to be supported.
3. Should propriety script language is admitted or do you prefer standard languages
4. How important is ‘proven technology’ for you?
5. The API of the environment needs to be specified clearly.
6. Should it be possible that data from the hub can be offered in xml-format to other systems?
Should it be possible that data can be imported from other systems in xml-format into the
hub?
7. The firm/organisation supplying the platform needs to guarantee continuity of the
platform.
8. Is management able to set standards for software use?
B Management
1. Should there be a central interface only accessible to the hub manager?
2. Should one be able to create new users
3. Should user statistics be kept of visitors of the public website
4. Should user statistics be kept of who is online in the collab
5. Should actions of collab-members be logged?
27
6. Should there be logs of the manipulation of public data
7. Should there be logs of the manipulation of private data
8. Should authorization be given by means of roles, not individual users
9. Should everything be accessible to all members of the collab
10. Should there be a clear separation between private webpages and collaboratory pages?
11. Should there be a clear separation between private webpages, collaboratory pages and the
public site?
12. Should the manager be enabled to overrule rights set by users?
13. Do the participants in the collaboratory need to retain control on their own contributions
14.
Complete control: the contribution can only be read by the author
15.
Shared across the collaboratory: the contribution is shared by all members of the
project
16.
ad hoc: the contributor decides each time with whom the contribution can be shared
17.
open: the contribution is visible to the general public
18.
closed: the contributor loses all right after uploading.
19. Should users be allowed to change passwords?
20. What kind of rights should be set on (various) objects (read, write, update)?
21. Suppose a file is not meant for reading. Should it still be found by an (internal) search
engine?
22. Should users of the public site be registered
23. Should there be a content management system for the public site?
24. Indicate the number of hours per week that you as leader of the hub can spend on
managing the site (allowing access to new users, setting rights, creating workflows etc)
C. Collaboratory
1. Is webmail needed?
2.
Should it be possible link this with existing accounts on the server
3.
Address book?
4. Should there be a mailing list
5.
Public lists
6.
Personal lists
7.
Import mailinglists
8. Integration with MS Outlook
9. Integration with mail software
10. Is a webforum needed?
11.And instant messaging?
12
Should sessions be stored?
13 Is audio and/or videoconferencing desirable?
14 Wiki
15 Online whiteboard
16
How detailed in terms of graphical options (diagrams, graphs etcetera)
17 Should one be able to make ToDo/Actionlists?
18
Should to lists be shared
19
Granted to third parties?
20 Calendar functionality
21
Shared calendar
22
Planning of meetings
23
Integration with MS - Outlook/Exchange of other (which one)
24
Synchronisation with PDA's
25
Automatic warnings
26
What kind of directories’ functionality is needed
28
27
Public directories
28
Personal directories
29
Group directories
30. Document routering/ workflow management options
Blogging functionality
Guestbook on public site
D. Material
What actually is to shared:
1. Text and spreadsheet files (e.g. as part of a dataset, documentation of sources, methods,
annotation of data or literature, research applications etcetera)
2
To be shared?
3
To be manipulated online? All types of files?
4 URL’s/Links (eg. To literature)
5
To be shared?
6 Other file types
7
To be shared?
8
Is online reading/manipulation possible?
10 If online reading or writing is not possible, do you need plug ins for these filetypes?
11
external databases (such as. MA Access, MySQL)
12
Statistical/graphical software (SPSS)
13
Reference software (Endnote, Reference Manager)
14 Incorperation of RSS Feeds?
15
To be shared?
16 Integration with search engines
17
Google
18
Picarta
19
Jstor
20
Scopus
21 Other, to wit …
E. Version control
1. How desirable is version management? In what form? One can think of an automatic
logging function that tracks all changes to a dataset, that archives the old versions, and that
sets versions numbers.
2. How desirable is a functionality that tracks changes within a dataset. Should there be a
logbook with annotations of changed data?
F. Metadata
1.What kinds of ‘administrative' metadata (author, day of creation, day of uploading, day of
last change, abstract) do you want to keep on the data collected within the collaboratory?
2. Is this to be done by hand or automatic?
3. Should it be possible to develop your own metadata scheme
4. Should the technical metadata (filesize, format type) be stored?
5. Should the metadata (e.g. authors) be protected through authorisation?
6. Should users be enabled to tag metadata?
7.
Should those tags be shared?
8.
Should they be individual
G Intellectual property
29
1. How important is it to make (and keep) visible individual contributions to the dataset?
What kind of citation of the data is foreseen? Do you want applications that allow for unique
digital identification of (parts of) the dataset? And should that be done automatic?
H Interface
1.How desirable is the option of different languages for the interface (N.B. only of some
elements of the interface).
2. How desirable is the option of changing the interface
3.
Colors
4.
Fonts
5.
Font sizes
6. How desirable is a search facility for the material collected in the collaboratory?
7.
On metadata
8.
Full text
9. Store search settings
I Security
1. Should scanning of material for viruses be installed?
2. Encryption on the line (SHTP, SSL)?
30
Appendix 2
Technische Rapportage HUBSLAB-project
(Digitale Infrastructuur deelproject IISG)
Opgemaakt door:
Overige leden:
Datum:
Versie:
M.Mieldijk (namens het testteam)
Ole Kerpel
Luciën van Wouw
Gordan Cupac
Jip Borsje
9 december 2007
0.1
31
Inhoud
1. Omschrijving Doel DI deelproject ‘Het opbouwen en testen van 3 verschillende
collaboratie systemen’
2. Organisatie
3. Ontwerp testomgeving
4. Omschrijving werkwijze testteam
5. Urenverantwoording
6. Bevindingen
7. Conclusie en aanbeveling
8. Bijlagen
32
1. Doel DI deelproject
Het doel van dit deel project is, ‘het uitbrengen van een aanbeveling van één van de drie
voorgestelde ‘collaboratiesystemen’.
Gestelde voorwaarden zijn:
• Testen van Sakai/Sharepoint/Liferay-Alfresco
• Maximale doorlooptijd tot keuze 2 weken
2.Organisatie
Projectleider/opdrachtgever
Naam:
Jan Kok
Kamernr.:
518
Email:
[email protected] of [email protected]
Telefoon:
020 6685866 of 020 8500483
Consultant
Naam:
Frans de Liagre Böhl
Kamernr.:
011
Email:
[email protected]
Telefoon:
020 6685866 of 020 8500421
Taak:
Consulent projectleider
Deelprojectleider
Naam:
Mario Mieldijk
Kamernr.:
8
Email:
[email protected]
Telefoon:
020 6685866 of 020 8500403
Taak:
Deelprojectleider / Aanspreekpunt consultant & projectleider
Installateur OS en Platvormen
Naam:
Mario Mieldijk
Kamernr.:
8
Email:
[email protected]
Telefoon:
020 6685866 of 020 8500403
Taak:
ICT medewerker tbv. Sakai/Liferay
Naam:
Jip Borsje
Kamernr.:
9
Email:
[email protected]
Telefoon:
020 6685866 of 020 8500403
Taak:
ICT medewerker tbv. Sharepoint
Naam:
Kamernr.:
Email:
Telefoon:
Taak:
Testers
Naam:
Kamernr.:
Email:
Telefoon:
Taak:
Naam:
Kamernr.:
Maarten Kroon
extern
[email protected]
020 6685866 of 020 8500403
Externe ICT medewerker tbv Sakai
Ole Kerpel
1
[email protected]
020 6685866 of 020 8500137
Tester / ontwikkelaar
Gordan Gupac
1
33
Email:
Telefoon:
Taak:
Naam:
Kamernr.:
Email:
Telefoon:
Taak:
[email protected]
020 6685866 of 020 8500421
Tester / ontwikkelaar
Luciën van Wouw
014
[email protected]
020 6685866 of 020 8500421
Tester / ontwikkelaar
34
3.Ontwerp Testomgeving
Algemeen
De testomgeving bestaat uit een drietal virtuele servers waarvan de Sakai en Liferay draaien
op een Linux Operating system en SharePoint op een Windows 2003 Operating system. Deze
virtuele servers worden geplaatst op de huidige VmWare ESX omgeving. De authenticatie van
de collaboratory systemen verlopen via het pakket of Operating system zelf. Van deze virtuele
omgeving zijn meerdere ‘snapshots’ gemaakt. Deze snapshots kunnen van dienst zijn indien
de omgevingen niet meer zouden fungeren. Er kan dan een stap terug in de tijd worden gezet,
zodat we snel weer kunnen testen. (Crisis Management)
Grafische weergave testopstelling
Overige gegevens:
Server:
Os:
Toegang:
paris.iisg.net (liferay/alfresco)
Linux CentOs 4.5 (Mysql4/php4.x/tomcat 1.5.12 jdk)
ftp / ssh / http / http port 8080
Server:
Os:
Toegang:
rome.iisg.net (sakai)
Linux CentOs 4.5 (Mysql4/php4.x/tomcat 1.5.12 jdk)
ftp / ssh / http / http port 8080
Server:
Os:
Toegang:
madrid.iisg.net (sharepoint)
Windows 2003 EE (sql2005, iis6, sharepoint)
ftp / ssh / http / http port 8080 / rdp
35
4.Omschrijving werkwijze testteam
A. Algemeen
Het testteam bestaat uit mensen die al jarenlange ervaring hebben op ICT-gebied. Echter
hadden we geen van allen eerder met collaboratie software, zoals
SAKAI/SHAREPOINT/LIFERAY, mogen werken. Voor de testers/ontwikkelaars was dit
natuurlijk een ’positief’ fenomeen. Zij konden namelijk de pakketten beter beoordelen op de
‘look and feel’. Maar aan de andere kant werd het ‘positieve’ fenomeen teniet gedaan doordat
iedereen in het ‘diepe’ gegooid werd. Kortom wij stonden voor een moeilijke opgave en
moesten we in een korte tijd een omgeving bouwen en daar ook nog advies over geven.
Wij hielden de opzet van ons testplan dus zo eenvoudig mogelijk :
- Maken inschatting collaboratie software tbv planning
- Systeembeheerders Installeren de Operating Systemen op de Virtuele machines
- Systeembeheerders installeren collaboratie software (best effort)
- Elke tester/ontwikkelaar test één pakket langdurig (ongeveer 18 uur) en houdt een
scoreboard bij
- Elke tester/ontwikkelaar test als cross-reference kortstondig een pakket van een
collega (ongeveer 12 uur) en past in overleg scoreboard aan.
- Deelprojectleider maakt rapport van bevindingen.
Mede door deze eenvoudige opzet konden we, ondanks dat onze ervaring en tijd beperkt was,
er toch voor te zorgen dat wij een goede aanbeveling zouden doen richting de
projectleider/consultant.
B. Wat hebben we niet getest!
Omwille de tijd hebben wij er voor gekozen om systeembeheerachtige zaken niet mee te
nemen in de tests cq. scoreboards. Dit zijn;
- Anti-spam / Antivirus mogelijkheden
- Email-verkeer
- Authenticatie verloopt alleen via het pakket of via de geleverde authenticatie-module
van het operating system
Deze zaken vinden wij wel van belang tijdens de pilot en/of implementatiefase.
36
5. Uren- en kostenverantwoording
Deel A Uren
Werkzaamheden
Perso
on
Uren
voor
Inventarisatie project/pakketten/uitschrijven
deelproject/uitschrijven aanbeveling/overleg
Consultant/Projectleider
Mmi
Installatie van extra geheugen in huidige
bladeservers
Installatie/configuratie/ van Virtuele machine
met Linux CentOs 4.x en Sakai
Installatie/configuratie van Virtuele machine
met Linux CentOs 4.x en Liferay/Alfresco
18
Ure
n
Na
40
Kosten
€ 2000,00
Rbe
3
3
€ 150,00
Mmi
Lwo
Oke
Externe
Mmi
Lwo
12
32
€ 1400,00
€ 400,00
12
13
€ 2600,00
Installatie/configuratie van Virtuele machine
met Windows 2k3 en Sharepoint 2007
Jib
16
20
€ 50,00
Support/Nazorg
Mmi
Jib
Mmi
Jib
Oke
Gcu
Lwo
24
15
€ 750,00
30
35
€ 1750,00
Oke
Gcu
Lwo
Oke
Gcu
Lwo
Mmi
30
18
€ 900,00
30
27
€ 1350,00
30
29
€ 1450,00
0
1
€ 50,00
Totaal:
205
233
€12850,00
Overleg tussen alle deelprojectleden
Testen van Sakai omgeving
Testen van Liferay/alfresco
Testen van sharepoint
Bestellen hardware
Deel B kosten
Soort hardware
Geheugen 2 x 2GB ecc tbv PE 1955
Dell Poweredge 2950
Totaal:
Kosten incl.
btw
€ 867,00
€4560,00
€5427,00
37
6. Bevindingen
Algemeen
De bevindingen van de collaboratie software hebben we eigenlijk al kenbaar gemaakt via een
scoreboard (zie bijlagen). Wij zijn alleen van mening dat bepaalde punten niet zichtbaar zijn,
maar toch mee moeten spelen in de beoordeling. Daarom hebben wij sommige bevindingen
even uitgelicht.
Sakai
Algemeen
Sakai is ontworpen voor de educatieve sector. Het is een instrument voor cursisten en
docenten om online documenten uit te wisselen en het biedt diverse communicatie
mogelijkheden. Het product bestaat nog niet erg lang, in 2005 is versie 1 opgeleverd. Er
wordt aan het product ontwikkeld, onlangs is versie 2.5 opgeleverd.
Zoeken naar informatie op het internet levert geringe links op. De eigen documentatie
pagina’s zijn voldoende, maar summier. Met name omtrent de installatie is de hoeveelheid
documentatie beperkt en verwarrend. Er is dan ook niet een levendige community die zich
met dit product bezighoudt. Volgens de website is het product 250 keer in productie
genomen. Er zijn wel 100 pilots die misschien in productie gaan.
Het product is ontworpen voor Firefox en Internet Explorer. Safari, Opera en andere
browsers zullen niet alle functionaliteiten kunnen tonen.
Installatie
Voordat wij met de installatie begonnen hebben wij eerst wat onderzoek gedaan op de
website. Hieruit bleek al snel dat wij meerdere tabbladen nodig hadden in onze browser om
alle installaties van de diverse afhankelijkheden te bekijken. Ze hadden wel een draaiende
demoversie, echter stond er bij dat patchen van deze installatie niet mogelijk was. Mede door
deze mededeling hebben wij toen besloten het vanaf de source op te bouwen. Eerst hebben
wij de afhankelijkheden bij elkaar gezocht. Op zich is dat niet veel werk, maar bij elke
afhankelijkheid was er wel iets met de versie. En het viel daarbij op dat veel afhankelijkheden
vele versies achterliepen. Ook de databasekoppelingen waren te ‘exact’ voorgeschreven, dit
zou je namelijk niet verwachten van een Open-source product.
Nadat wij de afhankelijkheden hadden geïnstalleerd konden we met de ‘build’ van Sakai
beginnen. Het opmerkelijke was dat hij toch nog meer pakketten (dus afhankelijkheden) via
het Internet aan het downloaden was. Gelukkig was na een tijdje de build gereed (build
succesfull) en konden wij de Tomcat-webserver starten. Maar helaas draaide de ‘verwachte’
portal niet. Na wat controles leek de Tomcat-webserver keurig te draaien, echter geen pagina.
Indien wij een index.jsp plaatste kregen we dat keurig te zien. Omdat onze ervaring niet
toereikend was om dit op te lossen hebben wij iemand ingehuurd om een diagnose te stellen
van onze installatie. Deze persoon kwam er achter dat bepaalde ‘java-classes’ niet goed waren
of zelfs niet aanwezig waren. Nadat hij de ‘java-classes’ uit de ‘demoversie’ naar de juiste
plekken had gekopieerd zagen wij eindelijk de verwachte ‘portal’. Echter nadat we waren
ingelogd met het test account kregen we hier en daar toch een foutmelding op het scherm.
We hebben toen maar besloten het pakket opnieuw te bouwen. We hadden immers toch de
source compleet en ook een externe ‘Tomcat-webserver’ specialist in huis. De ‘build’ was dan
ook snel geregeld en nu met het beoogde resultaat, een werkende Sakai. De logging van
Tomcat-webserver gaf nog wel een paar foutjes, maar deze hadden we snel opgelost. We
konden het nu onderwerpen aan de tests.
38
Gebruikers gerelateerde ‘highlights’
Algemeen
Het pakket is uitermate geschikt voor iedereen die wel eens beheer heeft gedaan van websites
of website onderdelen. Dit pakket is intuïtief en elementair, mede dankzij de strakke lay-out
en eenvoudig opzet. Het is een platform dat in eerste instantie is bedoeld als instrument bij
(online) cursus geven of volgen. Bij een cursus staat meestal vast wat voor agendapunten
(lesuren) er zijn en wat voor taken er aan gekoppeld (huiswerk) zijn. Het is niet geschikt om
er visueel aantrekkelijke websites mee te maken met behulp van een flexibel CMS.
Automatische nummering van nieuwe versies, beschikbaar stellen houden van oudere versies
Sakai kent geen versie beheer en doet daar vooralsnog geen ontwikkeling in. Onze inschatting
is om een koppeling te maken met een open source pakket als cvs en het niet te laten
integreren in Sakai zelf, aangezien Sakai nog in ontwikkeling is en men bij iedere upgrade
moet checken of het nog werkt.
Logboek van handelingen van een deelnemer
Wij hebben deze functionaliteit niet kunnen vinden en dus niet kunnen testen. Willen we dit
verwezenlijken, dan moet er onderzocht worden in hoeverre het geïntegreerd kan worden, of
dat het juist handiger is om dit buiten het pakket te doen. Wel denken wij dat de structuur
van gebruikers en gebruikersrollen bruikbaar zullen zijn.
Directories/Publieke directories/Persoonlijke directories/Groepsdirectories
Sakai biedt de mogelijkheid om documenten te delen met anderen. Men kan geen echter geen
directories creëren en delen met anderen. Wel kan men een serie documenten met anderen
delen hetgeen op hetzelfde neerkomt. Zonder dat deze functionaliteit in het pakket zit zou je
met goede afspraken in die richting kunnen komen.
Kleuren/Lettertype/Fontgrootte
Sakai is intuïtief en overzichtelijk. Het aanpassen van kleuren, lettertypen en fontgrootte kan
m.b.v. de browser zelf, maar het zal niet al te ingewikkeld zijn om stylesheets aan te passen.
Het kost echter zeker een dag of drie ontwikkeltijd om erachter te komen waar stylesheets
staan en hoe men de gebruiker de mogelijkheid kan geven te kiezen.
Zoekmogelijkheden/Op Metadata
Deze functionaliteit biedt Sakai wel, maar we hebben het niet zien werken. De reden daarvan
is vooralsnog onduidelijk.
ToDo-, Actielijsten maken / actielijsten delen
Sakai voorziet in een agenda functionaliteit, maar koppelt hier geen acties en of gebruikers
aan. Om dit te verwezenlijken moet je de core van het systeem in en ook goed doorgronden.
Dit kost veel tijd. Het systeem voorziet er niet in en ontwikkelt dit (voorlopig) ook niet. Wij
denken dat het voortkomt uit het feit dat Sakai in eerste instantie is bedoeld als instrument
bij (online) cursus geven of volgen. Bij een cursus staat meestal vast wat voor agendapunten
(lesuren) er zijn en wat voor taken er aan gekoppeld (huiswerk) zijn.
Kunnen koppelen met bestaande accounts op mailserver/ Integratie met MS Outlook
De mail functionaliteit van Sakai is gering. Men kan een email bericht sturen. Een koppeling
met Outlook is dan ook niet (of alleen via een omweg) mogelijk. Dit is meestal te relateren
aan het feit dat het Open-Source is.
39
Ict gerelateerde ‘Highlights’
Antivirus
Het pakket heeft geen standaard voorziening voor het koppelen van een antivirus pakket. De
enige oplossing kan zijn dat er een antivirus-pakket op het Operating system wordt
geïnstalleerd. De logging van geweerde bestanden/virussen en dergelijke is dus alleen uit te
lezen door de systeembeheerder.
Performance
Ondanks dat wij geen performancetest hebben gedaan, kunnen we aannemen dat dit pakket
geen superzware hardware nodige heeft om goed te draaien. Dit is mede te danken aan de
eenvoudig opzet en de weinige plug-ins die wij getest hadden.
Patchmanagement/beheer
Omdat het pakket alleen patchmanagement ondersteund op de source, lijkt het ons niet
eenvoudig om te patchen. De vele afhankelijkheden van versies,oude pakketten en constante
beschikbaarheid van websites maken het er niet gemakkelijker op. Het lijkt er op dat per
versie je liever het pakket er naast kan opbouwen en dan de data migreert.
Ontwikkeltijd
Omdat Sakai niet alle functies heeft die er gewenst is, zijn wij van mening dat we behoorlijk
veel tijd kwijt zijn aan het ontwikkelen van extra functionaliteit.
Conclusie Sakai
Communiceren en documenten delen kan prima met Sakai, het is intuïtief en eenvoudig in
gebruik. Maar helaas voorziet het pakket niet in samenwerken in de zin van plannen,
afspraken maken en taken aan personen koppelen. Dat komt waarschijnlijk voort uit het feit
dat het voor cursisten en docenten is geschreven. Over het algemeen zijn daar taken en data
al bekend.
Gezien de hoeveelheid functionaliteiten die Sakai tekort komt ten opzichte van de twee
andere software pakketten zal het hoogst waarschijnlijk niet lonen om tijd te steken in het
(laten) ontwikkelen van de ontbrekende elementen. Redenen hiervoor:
- Zelf ontwikkelen of laten ontwikkelen betekent geen officiële ondersteuning van de
makers van het oorspronkelijke product.
-
Bij een upgrade of migratie van het product moet altijd gecontroleerd worden of de
aangebouwde functionaliteiten nog goed werken, want niemand kan deze garantie
geven.
-
Sakai heeft een tamelijk kleine community van ontwikkelaars en geïnteresseerden die
zich bezig houden met het verbeteren en verder ontwikkelen van het product. De
eerste versie is in 2005 opgeleverd en ondanks dat er verder wordt ontwikkeld aan
onder andere whiteboard, blogs blijft het een pakket dat zich richt op de educatieve
sector: Sakai is een online samenwerk– en leeromgeving.
-
Aanbouwen van functionaliteiten houdt in dat er veel resources ingezet moeten
worden en ook moeten blijven. De kennis zou dan in huis gewenst zijn. Dit is
moeilijker te garanderen, omdat er veel mensen bij het IISG op ‘tijdelijke’
40
contractbasis werken. Je zou dit af kunnen vangen door een goede documentatie.
Maar over het algemeen kost dat ook veel tijd.
-
De kosten om te zorgen dat het systeem ‘veilig’ blijft door patches e.d. zijn hoger dan
de andere pakketten. Vooral het opnieuw ‘builden’ van het pakket en testen er van
kosten veel tijd.
Kortom: Alle punten afgewogen komen wij tot een negatief advies.
Sharepoint
Algemeen
Sharepoint server 2007 is ontworpen voor het ‘grotere’ bedrijfsleven. Het heeft hoge
hardware eisen en heeft bij veel ‘load’ ook vele servers nodig die ieder een ‘Sharepoint-taak’
op zich neemt. Het is absoluut een instrument waar collaboration mee mogelijk is. Het biedt
heel veel mogelijkheden, maar dat maakt het dan ook weer complex om te implementeren.
Vendor lock-in is met dit product aanwezig. Wij hebben getest met Microsoft Sharepoint
2007.
Op het Internet is een schat aan informatie omtrent dit product te vinden. Er zijn officiële
Microsoft Sharepoint communities en publieke Sharepoint communities die zich alleen met
dit product bezighouden. Het product is enorm veel keer in productie genomen. Op de
website http://www.microsoft.com/sharepoint/prodinfo/evidence.mspx staan meerdere
succes stories.
Het product is vooral ontworpen voor een beperkt aantal browsers, te weten;
- Level 1 Web browsers (alle functionaliteit): Win 2000, Win XP, Win2003, Vista client
with IE6 or IE7
- Level 2 Web browsers (beperkte functionaliteit): Win 2000, Win XP, Win2003, Vista
client with Firefox 1.5, Mozilla 1.7 or Netscape 8.1, Unix/Linux with Firefox 1.5 or
Netscape 7.2, Mac OS-X with Firefox 1.5 or Safari 2.0
Vreemd genoeg wordt Firefox 2.x dus niet ondersteund, ook niet in level2.
Sharepoint is een closed source product en dus licentie afhankelijk. Aangezien de meest
onderzoeksinstellingen, universiteiten en hoge-scholen aangesloten zijn bij Surfdiensten
vallen deze kosten erg mee. Maar neemt niet weg dat de keuze van implementatie ook vele
licenties met zich mee kan brengen. En veel goedkope licenties is uiteindelijk toch weer een
hoge kostenpost.
Installatie
Voordat wij met de installatie begonnen hebben wij eerst wat onderzoek gedaan op de
website. Hieruit blijkt al snel dat Sharepoint vele implementatie mogelijkheden bied. Dit was
dus een moeilijk punt, waar richten we Sharepoint voor in. We besloten toen maar te kiezen
om alle instellingen standaard te houden en gewoon alle services gestart te krijgen. De Sqlserver, Search/Indexing server, IIS webserver en Sharepoint Server stonden dus allemaal op
de zelfde server, hetgeen veel ‘load’ gaf. Maar aangezien het met Vmware Esx eenvoudig is
het geheugen te vergroten, was dit weer eenvoudig opgelost.
De installatie is op zich redelijk eenvoudig, maar kost redelijk veel tijd. De vele patches die
aanwezig waren op het Internet zijn daar zeker debet aan. Er zijn overigens over het
algemeen geen trucjes (registerhacks) nodig om het pakket aan de praat te krijgen. Ook werkt
Sharepoint maar met één database, de Sql server van Microsoft zelf. Wij hebben gekozen voor
Sql2005 Sp2, maar Sql2000 Sp3 had ook gekund.
Aangezien wij weinig tot geen ervaring hadden met het product zijn we maar gewoon
begonnen met de admin website van Sharepoint. De hint en tips die daar stonden, de
omvangrijke informatie op het Internet , ‘best practices’ en de community site waren we in
41
staat om een standaard site te bouwen. Na wat ‘trail and error’ leek het er dan ook op dat we
‘iets’ hadden draaien waar de testers wat mee konden doen.
De rechten structuur is echter redelijk complex, aangezien het om een product gaat dat zowel
interne als externe diensten kan leveren. Wij hebben er voor gekozen om vaste gebruikers
aan te maken binnen het Operating system. Deze konden dan door de tester gebruikt worden.
Zonodig maakte de tester extra gebruikers aan.
42
Gebruikers gerelateerde ‘Highlights’
Algemeen
Het pakket is uitermate geschikte collaboratie software en kan ook meer dan dat. Het aardige
is wel dat indien er een website wordt aangemaakt er meteen een mobiele versie beschikbaar
is met dezelfde inhoud. Iedereen met een Smartphone of PDA is dan ook meteen geholpen.
De front-end is elementair en door themes of ‘sharepoint designer’ geheel aan te passen. Het
is een platform dat goed past in een Microsoft kantoor omgeving. Alle componenten sluit
‘bijna’ naadloos aan op de Office (2007) pakketten die men op een werkplek heeft
geïnstalleerd.
Logboek van handelingen van een deelnemer
Sharepoint biedt alleen een algemeen overzicht ‘usage reporting’. User logging is alleen
mogelijk via de log-files van IIS en indien dat gewenst is zou een extern programma als
‘Webtrend’ gebruikt kunnen worden.
Directories/Publieke directories/Persoonlijke directories/Groepsdirectories
Sharepoint biedt de mogelijkheid om documenten/pictures te delen met anderen. Men kan
directories creëren en delen met anderen. Echter vragen wij ons af of persoonlijke directories
van gebruikers wel gewenst zijn. Ze kunnen dan de portal gebruiken voor een geheel ander
doel. De site admin kan niet goed controleren wat de mensen in hun ‘private’space doen. Of
dat een bezwaar is weten wij dus ook niet.
Gebruikers moeten zelf wachtwoord kunnen wijzigen
De eenvoudige implementatie die wij hebben gedaan biedt alleen mogelijkheden om lokaal
op het Operating system gebruikers aan te maken. Er bestaat een mogelijkheid tot het
toevoegen van meerdere ‘authentication providers’. Deze zouden er voor kunnen zorgen dat
men zich ‘web-based’ kan aanmelden. Op het Internet zijn verschillende voorbeelden te
vinden. Tijdens een implementatie kost dit dus wel wat tijd om uit te zoeken.
Scheiding privé collab publiek
Er bestaat een mogelijkheid om site-wide zones in te richten. Bijvoorbeeld publiek (extranet),
alleen voor collaboratie gebruikers (intranet) enz.
Voorbeeld publieke functie zie http://sharepoint.microsoft.com/sharepoint/default.aspx .
Online bewerken
Indien je lokaal Ms-Office hebt geïnstalleerd is er een volledige integratie mogelijk. De
eenvoud van versiebeheer is dan zeer goed geregeld. Echter is het wel aan te bevelen dat je
Ms-Office 2007 hebt.
Ondersteuning Firefox 2.x
Volgens Microsoft wordt Firefox 2.x niet ondersteund, echter uit de test blijkt dat Firefox 2.x
prima werkt, hetgeen wel met beperkte functionaliteit.
Ict gerelateerde ‘Highlights’
Antivirus
Het pakket heeft standaard voorzieningen voor het koppelen van een antivirus pakket. De
implementatie er van lijkt simpel door een vinkje te zetten. Wij hebben echter niet terug
kunnen vinden waar wij het antivirus pakket kunnen koppelen. Het lijkt ons vreemd dat het
zo maar gaat werken. Het aan- en uitzetten kan worden geregeld door de site-wide admin.
Performance
Ondanks dat wij geen performancetest hebben gedaan, kunnen we aannemen dat dit pakket
behoorlijke hardware eisen heeft om goed te draaien. Door de servers te splitsen kan men de
‘load’ goed verdelen.
43
Licenties
Aangezien dit product closed source is ben je afhankelijk van licenties. Afhankelijk van de
implementatie eisen en toekomstplannen kan dit dus een redelijke kostenpost zijn.
Patchmanagement/beheer
Microsoft gaat een commitment aan ten aanzien van het product. Hiermee waarborg je de
veiligheid van het product. Er zullen, indien nodig, patches worden uitgebracht voor
Sharepoint. Automatic updates zorgt er dan voor dat systeembeheerders continu op de
hoogte worden gesteld. Men moet er rekening mee houden dat bij gelijke bezetting Microsoft
Producten iets zwaardere eisen stelt aan de hardware. Het splitsen van servers is dan eerder
aan de orde wat dus meer beheer opleverd.
Ontwikkeltijd
De ontwikkeltijd die nodig is ligt hem vooral in de mogelijkheden van authenticatie. Indien je
lid bent van een Active Directory , zoals bij het IISG, is het snel geregeld. Echter indien je
externen wil authenticeren krijg je te maken met een stukje ontwikkeling van pagina’s. Deze
pagina’s kunnen er voor zorgen dat er automatisch gebruikers worden aangemaakt op het
systeem.
Conclusie Sharepoint
Sharepoint is een pakket dat zeer uitgebreid is. Nieuwe web-parts aanmaken via ‘Sharepoint
designer’ is geen probleem, maar extra functionaliteit toevoegen aan bestaande Sharepoint
web-parts is niet mogelijk. Het heeft een gedegen uiterlijk en is voor de meeste gebruikers
van Microsoft producten erg herkenbaar. De hardware eisen zijn hoog en daarom lijkt het al
snel de moeite waard om servers te splitsen. Indien een pakket van dit formaat
geïmplementeerd wordt moet men eerst even goed weten wat men wil. Beheerders opleiden
is noodzakelijk. Maar één ding is zeker als mensen hiermee gewend zijn te werken is het maar
de vraag of een Open-source variant het kan evenaren.
Kortom: Alle punten afgewogen komen wij tot een positief advies, indien er maar tijd
voldoende is om het te implementeren.
44
Liferay/Alfresco
Algemeen
Liferay portal server is ontworpen voor iedereen die het maar gebruiken wil. Het is
laagdrempelig en het heeft geen hoge hardware eisen. Het is een goed en simpel instrument
waar collaboratie zeker mee mogelijk is. Het biedt veel mogelijkheden en is eenvoudig te
implementeren. Door de Java ‘motor’ kan men Liferay op verschillende operating platformen
draaien. Liferay heeft nu versie 4.3.5 in diverse smaken ter ‘download’ aangeboden.
Zoeken naar informatie op het internet levert voldoende informatie op. Er zijn manuals, blog
sites, forums en het heeft ook een ‘wikipedia’ achtige site opgericht, genaamd Liferaypedia.
Het product is enorm veel keer gedownload en vermeld op de website
http://www.liferay.com/web/guest/stories meerdere succes stories. Het lijkt er dus op dat
het een gedegen product is. Op de website is niet echt een lijst te vinden met supported
webbrowsers. Wij denken dat in verband met de open-source gedachte dat Internet Explorer
en Firefox zeker geen problemen opleveren.
Alfresco is een CMS component die via een plugin geladen kan worden. Het krijgt niet de
officiële support van Liferay, maar is wel via hun te downloaden. Aangezien Alfresco een
‘technology partner’ is mag je verwachten dat het een goede aanvulling is voor de Liferayportal.
Installatie
Net als bij de andere pakketten hebben wij eerst even onderzoek gedaan op de website.
Hieruit bleek dat Liferay je heel veel mogelijkheden biedt om tot een succesvolle installatie te
komen. Je kan voor verschillende combinaties Liferay/java-webserver/database kiezen.
Omdat we een heel klein beetje ervaring hadden met het starten en stoppen van Tomcatwebserver op Linux hebben we die versie maar gekozen. De installatie was overigens super
éénvoudig. Je pakt het installatiepakket uit, zet de rechten en paden even juist en start de
Tomcat-webserver en voila, een draaiende Liferay-portal. Het bleek al snel een ‘life’ kopie te
zijn van de huidige website www.liferay.com. En zoals de online-manual keurig betaamd log
je in als de testgebruiker. Deze gebruiker heeft dan ‘admin’ rights, wij konden echter de
‘admin’modules niet vinden. Na lang geklik bleek dat je even naar de ‘hoofd site Liferay Inc.’
moest gaan. Daarin stond een aantal ‘private pages’ die er voor konden zorgen dat je
daadwerkelijk adminstrator taken kon uitvoeren.
Om het Alfresco component toe te voegen konden wij gewoon naar een plug-in pagina gaan
en door een simpele klik werd de plug-in binnengehaald via het Internet en geïnstalleerd. Dit
leek uiterst simpel, maar helaas zagen we niet zoveel gebeuren. Hier en daar zagen we wel dat
de component geladen was. Maar eigenlijk zagen we in eerste instantie de meerwaarde niet.
Omdat de tijd begon te dringen zijn de testers toch maar begonnen met hun onderzoek. We
hebben tussendoor Alfreso Community Edition geïnstalleerd naast de Liferay installatie.
Echter hielp dit in eerste instantie niet en zijn we er niet meer mee verder gegaan.
45
Gebruikers gerelateerde ‘Highlights’
Algemeen
Het pakket is uitermate geschikt als collaboratie software. Het heeft vele plug-ins enop het
Internet zijn vele themes beschikbaar. De front-end is helder, gebruikersvriendelijk en geheel
aan te passen. De gebruikers alsmede de ‘site-admin’ zullen de ergonomie en ‘useabilty’ van
het pakket snel waarderen.
Uploaden van documenten
Het uploaden van documenten is, net als bij Sharepoint, gecontroleerd door een extensie
filter. Deze extensies zijn alleen aan te passen door een ICT beheerder en is een ‘site-wide’
instelling. Natuurlijk kan men voor de implementatie de bestaande lijst al aanvullen met alle
nu bekende extensies.
Workflow portlet
Deze functie werd niet echt nodig geacht door de ‘hubs-trekkers’, maar wel door het testteam.
Helaas kregen wij deze portlet niet werkend. Het probleem is ook bekend bij de support van
Liferay en wordt er een oplossing aangedragen. Deze oplossing zouden wij eigenlijk moeten
testen, tot op heden hebben wij dat niet gedaan. De prio lag voor de ‘hubs-trekkers’ erg laag.
Userlogging
Deze functionaliteit wordt geregeld via ‘google-analytics’ en is dus extern geregeld. Het geeft
redelijke informatie. Of het voldoende en gewenst is hangt af van de ‘exacte’ wensen van de
hubs trekkers. (privacy?)
Email/kalender/todo’s
Liferay blinkt niet uit in het uitwisselen van gegevens via kalender, email of todo’s. In een
kantooromgeving is dit een ‘must’, echter vereist men dit niet in dit project
ICT gerelateerde ‘Highlights’
Antivirus
Het pakket heeft geen standaard voorziening voor het koppelen van een antivirus pakket. De
enige oplossing kan zijn dat er een antivirus-pakket op het Operating system wordt
geïnstalleerd. De logging van geweerde bestanden/virussen en dergelijke is dus alleen uit te
lezen door de systeembeheerder.
Performance
Ondanks dat wij geen performancetest hebben gedaan, kunnen we aannemen dat dit pakket
lage hardware eisen heeft om goed te draaien. Maar naarmate het aantal plug-ins toeneemt
zal dit wel gecompenseerd moeten worden door extra hardware, vooral geheugen is dan een
belangrijke factor.
Patchmanagement/beheer
Liferay heeft een goede organisatie en levendige community, daardoor mag je verwachten dat
er regelmatig patches uitkomen. Deze patches zijn gemakkelijk te downloaden en te
installeren via de ‘admin plug-ins’. De automatisch update checker geeft voldoende
informatie over welke versie er nu draait en welke er beschikbaar is. Het lijkt er op dat Liferay
weinig onderhoud behoeft.
Ontwikkeltijd
Er zal tijdens een implementatie rekening gehouden moeten worden met extra ontwikkeltijd
die nodig is voor de authenticatiemodule. Er zijn een legio mogelijkheden beschikbaar, maar
aangezien het systeem zowel een publieke als private functie heeft is er soms een dubbele
authenticatie mogelijkheid gewenst. Bv. Active Directory en Lokaal. Om dit voor elkaar te
krijgen zal je iets moeten ontwikkelen.
Indien er meer flexibiliteit gewenst is in het design van de website, dan zul je voor de Alfresco
plugin extra tijd moeten reserveren. Tot op heden hebben wij deze niet goed werkend
gekregen.
46
Portlet ontwikkeling
Dankzij de Service Oriënted Architecture is het eenvoudig om eigen gebouwde
functionaliteiten toe te voegen. Dit maakt het pakket erg flexibel.
Conclusie Liferay/Alfresco
Liferay is een zeer compleet pakket. Mensen zullen zich, na een korte inwerkperiode, snel
thuisvoelen in de eenvoudig, maar toch complete opzet. Er zijn vele plug-ins aanwezig,
beheer is eenvoudig en het pakket voldoet daarom ook aan ‘bijna’ allee eisen die gesteld zijn.
Wil men dit product ook Integreren binnen de kantoorautomatisering van bv. het IISG, dan
kan het zijn dat dit pakket tekort schiet.
Kortom: Liferay krijgt van ons een positief advies. Zeker gezien de eisen en de doorlooptijd
van dit project. Echter wil men een goede integratie met een bestaande Microsoft
kantooromgeving dan zakt het advies naar middelmatig.
7. Aanbeveling/Conclusie
Wij hopen met dit rapport en de scoreboards inzicht te geven in de geteste collaboratie
software. Helaas waren we door gebrek aan tijd niet in staat om het gehele scoreboard te
testen. Wij hebben geprobeerd de belangrijkste dingen er uit te pakken. Sommige opties
waren op dit moment voor de Hub-trekkers niet echt belangrijk, maar hebben wij toch meer
prioriteit gegeven. Dit komt doordat wij hebben geprobeerd te kijken naar de toekomst.
Bijvoorbeeld zaken zoals Agenda functionaliteit / to do’s e.d werden niet als prio gezien.
Echter denken wij dus dat het best handig kan zijn om bijvoorbeeld seminars / releasedata
van onderzoeksdocumenten wel in een gemeenschappelijke agenda te stoppen. Het zijn geen
dwingende dingen, maar wel een leuk extraatje om mensen te informeren.
Doordat sommige omgevingen bij de start meer tijd nodig had hebben we een kleine
aanpassing moeten maken in planning ons testplan. De cross-reference die we voor ieder
pakket voor 12 uur gepland hadden, hebben we laten vervallen door een andere methode toe
te passen. De cross-reference is wel gebleven, maar dan gezamenlijk met de andere tester.
Dat bespaarde dan weer een hoop gezoek voor de cross-reference tester.
Hieronder nog even een kort overzicht in kernwoorden
Sakai: Zeer intuïtief, te eenvoudig, beheer lastig, gemiddelde hardware belasting , patches
lastig, support lastig, opleiding niet per sé nodig
Sharepoint: Meest uitgebreid, implementatie duurt langer, licenties, vendor lock-in,
patches gegarandeerd, support gegarandeerd, zware hardware belasting, intuïtief voor
gebruiker, beheer eenvoudig na implementatie, opleiding benodigd voor beheerders,
toekomst gericht.
Liferay: Zeer compleet, gemakkelijke implementatie, populair, support voldoende, beheer
eenvoudig, opleiding niet per sé nodig, patches eenvoudig, veel mogelijkheden voor
databases. Lage tot gemiddelde hardware belasting.
Het testteam is het er gezamenlijk mee eens dat wij, gezien de tijdsdruk en gestelde eisen, dat
Liferay eigenlijk de enige is die aan alle gewenste eisen voldoet. Echter zijn we ook van
mening dat Sharepoint absoluut meer potentie heeft in de toekomst. De talrijke functies en
mogelijkheden bieden vele omgevingen en kan dan als breder instrument worden ingezet.
Maar helaas zitten aan al deze mogelijkheden ook een keerzijde, het kost enorm veel tijd dus
geld. We laten de aanbeveling dus een beetje ‘open’. Enerzijds een product dat zeer goed
voldoet op dit moment en aan de andere kant een product dat veel meer biedt in de toekomst.
Wij wensen de projectleider en stuurgroep dus veel succes met het maken van de ‘echte’
keuze. Wij zijn natuurlijk bereid om eventuele onduidelijkheden nog eens nader toe te
lichten.
Namens het testteam,
Mario Mieldijk
Hoofd systeembeheer IISG
47
8.Bijlagen
Bijlage 1 :
Algemene tips, vragen en opmerkingen
Bijlage 2:
Scoreboard Sharepoint
Scoreboard Sakai
Scoreboard Liferay/Alfresco
Bijlage 1 Algemene tips, vragen en opmerkingen
Authenticatie:
Wat is er door de ‘site admin’ gewenst?
-ICT-ers maken de accounts aan (systeembeheerders)
-Site admins nodigt mensen uit
-Gebruiker vraagt zelf aan via website en ‘site admin’ honoreert de aanvraag
-Gebruiker regelt alles zelf
Design:
Wie brengt het ‘design’ aan van de portals?
-Is dat site-wide
-Is het per portal
-Moet de site-admin het doen
-ICT-ers maken de sites (publiekdiensten)
-Is design wel belangrijk en heb je dan wel Alfresco nodig ?
Directories:
Wat is de gewenste situatie voor Public- Private Directories
-Is het wenselijk dat site gebruikers een private directory krijgen
- Of is het voldoende dat men via rechten hun privé bestanden ontoegankelijk voor andere
gebruikers maken
Limieten:
Worden er eisen gesteld aan limieten per portal
-Is het wenselijk dat iemand een file kan uploaden van 5 MB terwijl ze in ‘VerWegLand’ maar
een 56k modem hebben.
-Moet de site-admin dat kunnen regelen of de ICT-er
48
Appendix 3 Collaboratory portal ISSH User Guide
February 2008
49
Introduction 51
About this document
51
Technical Information 51
Used symbols
51
I. General set up: Portal and Collaboratories
52
The Portal
Fout! Bladwijzer niet gedefinieerd.
The Collaboratories
52
II. Collaboratory management
54
Registering Users and User permissions – the Administration page....................................54
Registering users 54
Standard roles 54
Setting permissions
55
Adding portlets and Pages ....................................................................................................... 58
Configuring portlets
58
CMS - Changing the texts in the closed section of the collaboratory.................................... 60
Editing existing texts
61
Creating new texts
61
Reusing existing texts 61
Changing the title
62
Deleting Texts 62
Announcements........................................................................................................................ 62
III. Logging onto the portal and working with the collaboratories 63
Loging on to the portal and navigating to your collaboratory............................................... 63
Login
63
Navigate to your collaboratory 63
Changing your account 63
Navigating a portlet
64
Saving your entries
64
IV. How to use the standard functionality 65
Storing and retrieving files – the tab page Documents ......................................................... 66
Creating folders 66
Storing files
66
Version management
67
Using the message board ......................................................................................................... 69
Opening categories, threads and messages
69
Adding threads and messages 69
Subscribing to a category or thread
70
Using the Calendar .................................................................................................................... 71
Adding events and setting reminders 71
Updating or deleting events
72
Importing or exporting events 72
50
Introduction
The IISH has set up an experimental portal for the international scholar community. This
portal has been designed to support research groups in their exchange of information on a
specific project. It concentrates on the possibility to share files in different formats (like
databases, text files of spreadsheets), to have discussions, to notify team members of coming
events, etc. Each research group is organized around a research-project. The specific place
within the portal dedicated to the activities of a research group is called community or
collaboratory.
About this document
This document serves as a user guide for scholars using the collaboratories. It is designed for
the administrators of the collaboratories, as well as the regular users.
With the aid this document, users should be able to perform basic activities within the
collaboratories. Basic activities consist of uploading files, starting discussions on the forum
etc.
Collaboratory Administrators have a wider range of activities, like registering users and
granting them permissions.
For the collaboratory administrators, the chapter II. Collaboratory management has been
added. Here administrative activities like user management, adding new functionality and
editing standard texts on the closed section of the collaboratory are explained.
Many of the suggestions in this document describe only one way to perform a specific task. In
most cases different routes can be taken to achieve the same goal. Do not hesitate to
experiment.
All examples and illustrations in this document are taken from one collaboratory designed for
a research project on Guilds on the Liferay platform version 4.3. In the mean time an upgrade
of the platform has taken place. This has resulted in a look and feel diverging from the
illustrations in this document. Also as the collaboratory administrator can change the look
and feel of the site, the illustrations might no longer be in tune with the actual site.
More help on the environment can be found in the Liferay user guides, which can be found on
http://content.liferay.com/4.0.0/docs/users/index.html
and
http://content.liferay.com/4.2/doc/user/liferay_4_portal_administration_guide/onepage/.
Technical Information
The IISH Portal has been developed on a Liferay platform. Liferay offers an Open Source
development environment for the creation of portals designed for collaboration. For more
information, visit http://www.liferay.com/web/guest/products.
Used symbols
In this document the following symbols/lettering are used:
[text]
Text
Text
Text
= Button labeled text
= tab page labeled Text
= A portlet
= A link
51
I. General set up: Portal and Collaboratories
The Portal
The portal consists of one central entry page and five different sites, each dedicated to a
specific research project (see Fout! Verwijzingsbron niet gevonden.). The Portal can be
found at https://collab.iisg.nl. In the upper right hand corner is a button behind which a pull
down menu is hidden (see Fig. 1).
After a user has logged on to the portal the pull down menu enables him to navigate to the
Fig. 1: Pull down menu for navigation through the
portal
collaboratories for which he has been registered (see Fig. 2).
The Collaboratories
Each of the community sites dedicated to a research project, the so called collaboratories, has
a part which is open to the public via the World Wide Web, the other part is open to
registered users only.
After logging on to the system, users can navigate to the collaboratories for which they are
registered with the aid of pull down menu (See Fig. 2). Another way to get to the
collaboratory site is to enter the URL listed in Table 1 in the browser. In this way the user will
be directed immeditaly to the collaboratory site open to public. Here he has another
opportunity to log on to the portal and immediately navigate to the closed section of the
collaboratory.
The collaboratory is administered by a collaboratory administrator, who in practice will also
be the leader of the research project. The collaboratory administrator registers users, grants
or revokes permissions and adds functionality.
Name
Portal Entry
Labor Conflicts
Internationalization
longitudenal microdata
Labour Relations
HisCo
Gilden
Collab
administrator
Sjaak van der Velde
Kees Mandemakers
URL
https://collab.iisg.nl
https://collabs.iisg.nl/web/
labourconflicts
http://chaos.iisg.nl/web/hsn
Karin Hofmeester
http://chaos.iisg.nl/web/labourrelations
Marco
van http://chaos.iisg.nl/hweb/isco
Leeuwen/Richard
Zijdeman
Tine de Moor
http://chaos.iisg.nl/web/guilds
52
Table 1: Overview of research communities and the locations of the
collaboratories
Each collaboratory site consist of multiple pages, depending on how the community
administrator has designed the site .The rule of thumb is that each page is dedicated to a
specific issue, e.g. file management or a message board.
Fig. 2: The public and private site of the Guilds Collaboratory
E.g. In Fig. 3 the starting page of the private collaboratory over Guilds is shown. It consists of
seven pages, each to be found under the green tabs just below the banner and named, ‘Private
community area’ (active), ‘Events’, ‘Documents’, ‘Links’, ‘Forum’, ‘Administration’ and
‘Contact’. Each page is in general dedicated to one ‘functional unit’, e.g. a message board.
Such a functional unit is coined a ‘portlet’.
Fig. 3: A private collaboratory consisting of 7 pages
53
II. Collaboratory management
Registering Users and User permissions – the Administration page
Registering users
Registering users and setting user permissions is a task for the collab administrator.
Everybody can register as a user. By pressing the [Create Account] on the Sign In portlet,
people get a fill out form through which they register themselves as guests (see Fig. 4)..
Fig. 4: Registration form
The Text Verification fields serves to fill out the rather cryptic code given in the gray box, just
over the field, h.l. the code is 3914. This code is to prevent registration of specific programs
roaming the web in search for vulnerable web servers. Once a person has registered himself,
the collab administrator must set his permissions.
Standard roles
For everything which can be seen on the display, like communities, pages, documents, forum
etc. permissions can be set in a very granular way. The authorization structure of the
collaboratory can become rather complex. The Liferay platform by default has three basic
user roles, ‘community administrator’, ‘community owner’ and ‘community member’.1
The templates have been designed for two roles only, sc. ‘community owner’ and ‘community
member’
A ‘community owner’ is the role of the collaboratory administrator. This role enables him/her
to:
1. add functionality (portlets) to the collaboratory
2. to configure the settings of portlets
1
It is advised, at least in the startup period, to stick to the template roles. If a collab administrator
distinguishes a well defined group within his research team, who ought to have different
permissions, he should write these permissions down and ask the portal owner for aid with the
implementation.
54
3.
4.
5.
6.
7.
to register users for the collaboratory
to set the permissions of users
to create users groups, set its permissions and to add users to these groups
to start a folder tree and categories for discussions on the message board.
to make full use of all portlets, e.g. creating sub folders and storing files, starting
discussion threads on the forum and add messages.
The ‘community member’ is entitled to create structures within portlets, e.g. creating sub
folders and storing files, starting discussion threads on the forum and add messages. A
community member however is not entitled to create categories on a message board or top
folders, let alone to add portlets, or change their configuration.
Setting permissions
Only collab administrators can set the permissions of a user. For this the collab administrator
has a page to his disposal only he can access: Administration. On this page he has the
opportunity to associate a user with a specific role via the Community portlet.
By activating the tab Communities I Own the community owner gets a list of all his
communities, including information on the number of members and the amount of users
online. Each entry in the list has a [Action] button which activates a pull down menu (see Fig.
5).
Fig. 5: Activating a pull down menu to enter settings for a collaboratory.
By choosing the option ‘Assing Members’, a form appears on which it becomes possible to
search for users who are currently not registered as community members, or to change the
permissions of members.
By default the tabpage Current is active, listing all current members and their permissions.
To see a list off all available users (that is all users registered on the portal) activate the tab
Available. It is also possible to search for a specific user, by entering his or her name in the
field ‘Search’ and press [Search Users] (seeFig. 6).
55
Fig. 6: Searching for users
In the list of users, mark the checkbox of the user you want to set permissions for and press
the link Assign User Roles. The user will be redirected to a form listing the aformentioned
roles. Marking the checkbox and pressing [Update Associations] will save the settings (see
Fig. 7).
56
Fig. 7: Available roles
57
Adding portlets and Pages
Adding new functionality is relatively easy. A user logged in as a community owner will have
the option to add portlets and pages to the collaboratory.
To add a new page, press the Add Page tab just below the banner. You will be prompted to
enter a name for the page and to save your entry after which a new page will be added.
Fig. 8: Activating the Content menu
Portlets can be added on all pages. In principle a page can contain more than one portlet. To
add new portlets to a page go to the pull down menu in the upper right hand corner and
choose ‘Add Content’.
A form will pop up listing a large number of categories of portlets to choose from. Clicking the
categories the available portlets will be shown (see Fig. 10). By pressing [Add] the portlet will
be added to the current active page.
Configuring portlets
The look and feel of all portlets can be manipulated. Also specific settings can be set, e.g. to
overrule the default permissions of user roles. Each portlet therefore has to icons to
manipulate these settings (see Fig. 9). E.g. if you want to change the standard text of an email
sent to the people subscribed to a thread on the message board. To change these setting click
the Configuration-icon.
Fig. 9: Changing the default settings of a portlet
58
Some portlets, especially those needing to communicate with other systems, like Mail and
SMS Text Messenger need a server side settings as well. To use these portlets, please contact
the Portal Administrator.
Fig. 10: Choosing new portlets
59
CMS - Changing the texts in the closed section of the collaboratory
On the pages of the collaborator texts have been added. The text titled Objectives in Fig. 11 is
an example of such a text. These texts have been added with the aid of a portlet called
Journal Content. This portlet enables you to add formatted texts to your site. The text
displayed is called an Article.
Fig. 11: A Journal Content portlet
To manipulate the content of a Journal Content you must edit the existing article, select an
already existing article or add a new article.
Fig. 12: Manipulating text content
60
Editing existing texts
If you want to edit a text (article) press the ‘Edit Article Icon’ (see Fig. 12). An interface will
pop up, enabling you to edit the text. You can add pictures stored in your Image Gallery
(see page 66, Storing and retrieving files – the tab page Documents).
Note that the text, an article, has an id. Each time you create a new text, it will be stored in
the journal content. In the right pane you can manage the different versions, tag them,
schedule the moment for displaying them and work with templates and predefined
structures.
Fig. 13: Editing texts
Creating new texts
To add a new text, press the ‘Add Article Icon’ (see Fig. 12). The same interface will pop up as
shown Fig. 13. This time however, there is no article id. The id will be generated after you
have saved your text for the first time. Be aware that a text will only be displayed after it has
been approved.
Reusing existing texts
You can set up a new Journal Content and add an existing text to it. Press the ‘Select
Article’ icon and an overview of all previous texts (articles) is given. By marking the checkbox
in front of one of the articles, you add it to the Journal Content.
61
Changing the title
To change the title of a Journal Content, simply double click on it and enter the title you want
(see Fig. 14).
Fig. 14: Changing the title of the Journal Content
Deleting Texts
Emptying the editor does not delete the article, but merely change it. To delete an Article text
press [Delete] in the upper right hand section of the editor (see Fig. 13).
Announcements
The start page of the closed off section of the collaboratories contain an Announcement
portlet. With this portal you can add simple text messages to the site. To change the text of
the announcement press the Configuration-icon (see Fig. 9) and alter the text.
62
III. Logging onto the portal and working with the collaboratories
Logging on to the portal and navigating to your collaboratory
Login
To log on to the portal surf to https://collab.iisg.nl. Enter your username and password and
press [Sign In] (see Fig. 15). If you do not have an account, press [Create Account] and you
will be redirected to the registration form (see Fig. 4).
Fig. 15: Logging on to the Portal
Navigate to your collaboratory
To navigate to the collaborator you want, either use the pull down menu behind the button in
the upper right hand corner (see Fig. 2) or click the links on the page (see Fig. 16).
Fig. 16: Links to the collaboratories
Changing your account
To change your account activate the pull-down menu behind the button in the upper right
hand corner (see Fig. 8) and choose My Account. You will be redirected to a form where you
can chance your personal settings.
63
Navigating a portlet
Most portlets consist of a number of forms, each displaying a specific aspect of the portlet.
E.g. the Document Library comes with three tabs: Folders, My documents and Recent
Documents, each representing the library in a different way.
Each portlet has a default view. While navigating through the portlet, you can always return
to the default view by pressing the Return to Full Page link in the upper right corner of the
portlet.
If you have navigated more than one level deep, the Return to Full Page however will bring
you back to the default view of the portlet, skipping all intermediate levels. In order to return
to the previous view activate the tab page <<Back is added (e.g. see Fig. 19).
Some portlets, like Document Library or Message Board contain folders, files or
messages, which can be manipulated. In general these are represented presented as lists,
showing each list item as a link. Clicking the link will open the object in question. E.g. within
the message board, clicking a Category will bring you to all threads ordered under this
category; clicking the thread will show all messages within that thread. Mutatis mutandis,
clicking a folder will show a listing of all documents in that folder; clicking a document will
start a download-dialog.
Fig. 17: The pop menu [Action] at the end of a row in the list-view
If a form has a list view of the items it contains, every row will have a button [Action].
Clicking this button will result in a popup menu to manipulate the entry in question. E.g. fig.
11 shows the pop-up menu of a message thread, enabling a user to delete the thread, or to set
permissions for it, to subscribe to it, etc. The options in the menu depend on the permissions
of the user.
Saving your entries
Each time you alter a text, enter an event etc. you have to press [Save]. If you navigate to a
different page without have saved your entries, these will be lost.
64
IV. How to use the standard functionality
The collaboratories are offered to the research groups with the following functionality preimplemented.
1. Document Library
For central storage of files. Files can be uploaded (and down), commented upon;
includes version management.
2. Message Board
For discussions centrally administered, includes the opportunity of attaching files to
messages. Contains notification functionality, e.g. by RSS.
3. Events (Calendar)
A central calendar for registration of events includes notification functionality.
4. Administration
Only available for users logged in as collaboratory administrator. Dedicated to the
registration of users, creating roles, setting user permissions, etc.
5. Journal
For adding (formatted) texts to the user interface of the portal.
In general each ‘functional unit’, known as ‘portlets’, is placed on a different page within the
collaboratory. Depending on the user permissions, the functions offered can differ, e.g. a
regular collaboratory member is not able to change the settings of a portlet or to add new
functionality or pages.
65
Storing and retrieving files – the tab page Documents
On the tab Documents two portlets are available, Document Library and Image
Gallery. Both portlets function more or less the same, safe for the lack of version
management in the Image Gallery.
The document Library supports the central storage of files. It is found under the page
Documents (see Fig. 18). In the document Library folders can be created and files can be
uploaded and downloaded and searched for.
Fig. 18: The Document Library
Creating folders
Only the collaboratory administrator is allowed to create ‘top folders’, say the highest level in
a folder hierarchy. All collaboratory members can create subfolders. To create a folder press
[Add Folder]. A form will pop up enabling you to enter a name and a description for the
folder.
Clicking a folder will open it, listing all subfolders and files.
Storing files
You can add files by pressing [Add Document]. A form popup enabling you to browse your
workstation for files (see Fig. 19). While storing files, you make a copy of the original on your
on your workstation. Changes in the file you’ve stored locally are made independently from
the copy in the collaboratory.
Please note that there is a physical difference between your workstation and the collaboratory
storage space. While working on the collaboratory you are actually working on a server which
might be located anywhere in the world.
66
Fig. 19: Uploading files to the collaboratory
In the field ‘Title’ you can enter a name. The file will be saved in the collaboratory under that
name and not the name it has on your workstation. Leaving the field empty will result in the
file having the same name it has on your workstation.
It is possible to store one and the same file with the same name within the document library.
You can add tags to a file, or choose from existing tags. The tags will serve as search terms.
Retrieving files
To retrieve a file from the document library, simply click on the file in the list view and load it
down to your workstation.
Version management
Of one of the same document a number of versions can be stored, tracked, commented upon
and administered. Each file automatically is saved as version 1.0.
To upload a different version of a document, navigate to the list-view of the document and
press the button [Action]. Choose the menu option ‘Edit’ from the popup menu (see Fout!
Verwijzingsbron niet gevonden.)
In the form that pops up you can again upload a file and add comments. You can even store it
under a different name. The file in question will however be registered as a newer version
(version 1.1) of the previous file. In the version overview the previous files are still available.
As the chance exists that while you are working on a file, someone else will upload a newer
version, the document library gives you the opportunity to lock a file. In the list view of a file
it is indicated whether a file is locked or not. If a file is locked, no newer version can be
uploaded except by the user who had locked the file.
To lock a file simply press the button [Lock] and the file will be locked for twenty four hours.
The lock will automatically expire after this time-frame.
67
Fig. 20: Version management
68
Using the message board
Opening categories, threads and messages
The Message Board is located on the tab page Forum. The message board consists of
several categories. Only the collaboratory administrator can add or delete categories.
In each category an infinite number of threads can be started. Threads can be started by any
standard collaboratory member.
Fig. 21: A message board containing two categories
To open a category click on the title. You will be redirected to a page which gives an overview
of all the threads (discussions) in that specific category. Clicking the thread will open the
thread and display all messages.
Adding threads and messages
To add a thread, decide first into what category it falls. Open the specific category by clicking
its name. Press [Post New Thread]. You will be redirected to a form in which you must fill out
a subject (will be displayed as the name of the thread) and the text of the first message.
To the text you can add links, files, email addresses etc. There might be a difference in how
you enter texts and how they are displayed. E.g. the message defined in Fig. 23 is displayed as
pictured in Fig. 22.
Fig. 22: A message on the message board
69
Fig. 23: Adding a thread and a message to the category ‘Record Offices & Entries’
To react on a message press the icon ‘Reply’ or ‘Reply with Quote’. You will be redirected to a
form as displayed in Fig. 23.
Subscribing to a category or thread
Users can subscribe to categories and threads. Each time a message or thread is added to
respectively a thread or a category, a mail will be sent to the email address you’ve defined in
your user account. In this way you keep informed about reactions on discussions even while
not logged into the portal.
70
Using the Calendar
A calendar is to be found on the Event page. In principle the calendar is seen by everyone in
the Collaboratory. Be aware that it has not been configured to register private appointments
which you want to keep private.
Adding events and setting reminders
To add an event to the calendar press [Add Event] or click the date on which you want to plan
the event. Enter a name, a time and a description (see Fig. 24).
Fig. 24: Adding an event
71
You can make it a repeating event and set reminders. Please note that only the person having
defined the event will be notified.
Updating or deleting events
To update or delete an event, press the [Actions] button on the right hand of the listed event
and choose the action you want to perform.
Fig. 25: Editing or deleting an event
Importing or exporting events
You can import and export appointments from other calendars, e.g. from your Outlook
calendar. The portal will export your Calendar in the ICS-format, which can be imported in
many different types of digital calendars.
72
Appendix 4 Technische Rapportage Liferay
Frans de Liage Böhl, juni 2008
Inleiding
De pilot heeft plaats gehad met het collaboratory platform Liferay (http://www.liferay.com).
Liferay is een veel gedownload open source collaboratory platform. Hoeveel van deze
downloads daadwerkelijk zijn geïmplementeerd is onduidelijk. Succesvolle implementaties
draaien o.m. bij de Christian Science Monitor, NCSA en een aantal overheidsdiensten van
verschillende landen.
Liferay heeft gespecialiseerde partners in o.m. Duitsland (Frankfurt) en Engeland (Londen).
Algemene opzet van Liferay
Webpagina’s
Liferay is een collaboratory-platform voor meerdere online samenwerkingsverbanden, dat is
opgezet als een portal. Dat wil zeggen dat er één pagina (URL) is via welke gebruikers toegang
kunnen krijgen tot een groot aantal achterliggende communities. Elk van die achterliggende
communities heeft een publiek gedeelte en een gesloten gedeelte. Het gesloten deel is alleen
toegankelijk voor mensen met een geldige usernaam en wachtwoord.
Een gebruiker kan zowel op de centrale portal pagina als op de afzonderlijke collaboratoryomgevingen inloggen. Eenmaal ingelogd heeft hij toegang tot al die community pagina’s waar
hij als gebruiker is geregistreerd. Er is dus sprake van een centraal beheer van gebruikers.
Zodra een persoon als gebruiker is geregistreerd heeft hij toegang tot een community pagina
indien de hub-trekker hem daartoe gerechtigd heeft. Ook maakt Liferay een privé pagina voor
hem aan.
Liferay biedt een aantal module, zgn. portlets, die elk specifieke functionaliteit bieden. Deze
portlets kunnen zeer eenvoudig aan een pagina worden toegevoegd en verder worden
geconfigureerd door iedere gebruiker die daartoe gerechtigd is.
Liferay Platform
Publiek
Portal-entry
toegangspagina tot
portal – centrale
inlog mogelijkheid
voor geregistreerde
gebruikers
Gebruik
er
Privé
pagina’s
Collaboratory
Gebruik
er
Gesloten
pagina’s
pagina
Open
pagina’s
P
u
b
l
i
e
k
73
Gebruikers
Het Liferay portal wordt geleverd met één super-user, de portal administrator. In eerste
instantie kan alleen deze gebruiker andere gebruikers aanmaken, hun rechten toewijzen of
afnemen, communities aanmaken enz.
Aangemaakte gebruikers bestaan alleen binnen het Liferay-platform. Er is geen relatie met
gebruikers (en hun rechten) op het IISG-netwerk.
Registratie van nieuwe gebruikers kan door de super-gebruikers zelf ter hand worden
genomen, zonder dat systeembeheerde gebruikers hoeft aan te maken.
Authorisatie
Toegangsbeveiliging binnen Liferay is verzorgd met behulp van gebruikersnaam/wachtwoord
combinatie.
Gebruikersrechten kunnen op verschillende manieren en niveaus vergeven worden. De
portal-administrator bepaalt in eerste instantie welke gebruiker welke rechten heeft.
Naast gebruikers zijn er ook gebruikersgroepen te creëren. Aan gebruikersgroepen is een set
van rechten te koppelen. Door een gebruiker aan een groep toe te kennen krijgt de
betreffende gebruiker dezelfde rechten als de groep.
Afhankelijk van de aard van de objecten kunnen verschillende soorten rechten gezet worden.
Bijvoorbeeld in de Document Library Portlet (het equivalent van een filemanager) kan
worden vastgelegd wie bestanden mag toevoegen en verwijderen, maar ook wie er de look en
feel van het Portlet mag wijzigen.
Liferay voorziet in een aantal standaard rollen. Gedurende de pilot bleek dat er geen
aanleiding was af te wijken van deze standaarden.
Implementatie
Geimplementeerde functionaliteit
Het Liferay portal is in relatief korte tijd opgezet. Implementatie bestond grofweg uit:
1. Ontwikkelen van een template voor het portal.
2. Ontwikkelen van templates voor vijf collaboratories .
Ad 1.
De volgende portlets zijn geplaatst op de portal-entry:
- Een portlet voor gebruikers om in te loggen
- Een journal content portal met een algemene tekst over het collaboratory platform
Ad 2.
De templates voor de collaboratories bevatte de volgende functionaliteit:
- Document Library
o Voor het centraal opslaan van bestanden en de mogelijkheid van deze
bestanden een lokale kopie te trekken.
- Message Board/Discussie platform
o Binnen LifeRay is deze functionaliteit zo opgezet dat het mogelijk is om
bestanden aan een bericht toe te voegen. Deze functionaliteit in combinatie
met een notificatie-mechanisme , zou de mail wel eens overbodig kunnen
maken.
- Kalender
74
-
o De kalender is geschikt voor het noteren van voor de collaboratory relevante
evenementen en niet voor het bijhouden en/of plannen van afspraken.
Announcements
o Voor het doen van centrale aankondigingen.
Daarnaast is een template neergezet voor de privé pagina van de Hubtrekker, met daarop
functionaliteit specifieke functionaliteit voor beheer van de collaboratory.
-
-
-
Community
o Portlet voor het beheer van de community en de rechten van de andere
gebruikers beheren.
Maatwerk
o Bovendien zal hij in dit portlet de mogelijkheid hebben gebruikers toe te
voegen aan het portal. Deze functionaliteit is niet standaard. Het portlet zal
hiervoor moeten worden aangepast.
Template gebruikersrollen
o Binnen alle community pagina’s zullen de Hubtrekkers twee standaard
gebruikersrollen ter beschikking staan waaraan zij gebruikers kunnen
toevoegen:
o Community administrator (Hubtrekker)
Heeft lees - en schrijfrechten binnen het portal. Mag bovendien
materiaal verwijderen, evenals portlets. Mag portlets configureren.
o Community member
Mag lezen en schrijven. Mag materiaal toevoegen, maar niet
verwijderen (ook eigen materiaal niet). Mag geen portlets
toevoegen, verwijderen of configureren. Geen recht gebruikers toe
te voegen of rechten te zetten.
Ontwerp templates
De template is gemaakt door de standaard CSS-settings te overschrijven. Het doorvoeren van
deze wijzigingen was niet ingewikkeld. Bovendien voorziet de website van Liferay in een
verzameling documenten/wiki’s/message board waarin beschreven is hoe het platform naar
eigen hand is te zetten. Hier breekt zich wel het open-source karakter op: de documentatie
loopt veelal ca. één versie achter. In de praktijk levert dat zelden problemen op. De
ontwikkelde templates zijn weggezet als prototype collaboratory.
Opzetten nieuwe collaboratories
Opzetten van een nieuwe collaboratory is in Liferay zeer eenvoudig. Nadat het systeem er een
heeft aangemaakt kun je deze nieuwe communities de look en feel van het prototype laten
overnemen.
Liferay community
Liferay heeft een goede organisatie en levendige community. Aanmelden van bugs en feature
requests is mogelijk via de centrale website. Een uitgebreid forum met meerdere
zoekmogelijkheden stelt je bovendien in staat om snel informatie op te diepen ten aanzien
van functionaliteiten, bugs en work-arounds.
Technisch beheer
Algemeen
75
Geinstalleerde versies
Gedurende de selectie- en test periode is met 3 versies Liferay gewerkt. Wij zijn begonnen
met versie 4.3.4. Omdat er een storende bug in deze versie zat zijn wij overgegaan naar versie
4.4.2. Hierin was de storende bug wel in opgelost, maar waren er nog twee ergerlijkheden.
Daarom hebben wij besloten om toen versie 5.0.1 uit kwam, deze te installeren.
Infrastructuur
De pilot met Liferay is uitgevoerd binnen navolgende infrastructuur:
Os:
Linux
CentOs
4.5
(Mysql4/php4.x/tomcat
Toegang:
ftp / ssh / http / http port 8080
1.5.12
jdk)
Browsers
Gedurende de pilot is er, althans bij ons weten, alleen met Firefox en IE (versie 5, 6 & 7)
gewerkt. IE versie 5 leverde problemen, doordat bepaalde functionaliteit daar niet te
gebruiken was en sommige schermen onbruikbaar zijn. IE 7 levert slecht in één geval een
slordige scherm opbouw, Helaas is dat in het hoofdmenu, dat desondanks wel te gebruiken
blijft.
Functionaliteit die is gebaseerd op propriety-technologie is zeer beperkt en waar dit
voorkomt is er tevens een alternatief voor andere browsers. Zo is het bijvoorbeeld in Liferay
versie 4 mogelijk om meerdere files in een keer up te loaden. Dit is echter alleen mogelijk in
browser die de implementatie van ActiveX versie x ondersteunen, dus wel in IE 7, maar niet
in Firefox. Echter, het is mogelijk voor een andere upload-mogelijkheid te kiezen.
Installatie
Liferay biedt je heel veel mogelijkheden om tot een succesvolle installatie te komen. Je kunt
voor verschillende combinaties Liferay/java-webserver/database kiezen. Het IISG heeft
gekozen voor een configuratie voor de Tomcat-webserver op Linux. De installatie was zeer
eenvoudig. Je pakt het installatiepakket uit, zet de rechten en paden even juist, start de
Tomcat-webserver en je hebt een draaiende Liferay-portal.
User management
Gebruikers van het Liferay portal hoeven niet noodzakelijkerwijs ook netwerk gebruikers te
zijn bij de organisatie die het platform ter beschikking stelt. Dit was van groot belang voor de
IT-afdeling van het IISG. Immers, vele participanten van de door het IISG opgezette
onderzoeksgroepen zijn zelf geen werknemer van het IISG. Systeembeheer heeft deze mensen
liever niet als gebruiker op het LAN. Daarnaast betekent de opzet van Liferay dat de
beheerders van de collaboratories volledig onafhankelijk zijn van systeembeheer voor het
aanmaken van gebruikers voor hun collaboratory.
Patch management
Bugs worden relatief snel opgelost. Wij hebben twee bugs aangemeld die, wat ons betrof,
‘showstoppers’ waren. In beide gevallen was er binnen 3 weken een nieuwe patch.
Over het algemeen komt Liferay ongeveer iedere anderhalve maand met een nieuwe patch.
Deze patches zijn gemakkelijk te downloaden en te installeren via de ‘admin plug-ins’. De
automatisch update checker geeft voldoende informatie over welke versie er nu draait en
welke er beschikbaar is.
76
Aanpasbaarheid
Lifeay is een open-source platform, geschreven in Java. Het biedt de mogelijkheid om zelf
portlets te ontwikkelen, bestaande portlets aan te passen of plug-in’s te schrijven om
koppelingen met andere applicaties tot stand te brengen. Aanpassingen en nieuwe portlets
kunnen aan de Liferay-community worden aangeboden. Het IISG heeft vooralsnog niet de
kennis in huis om zelf portlets te ontwikkelen. Hiertoe zou opdracht gegeven kunnen worden
aan strategische partners van Liferay. Daarvan zijn er geen in Nederland gevestigd.
Vanzelfsprekend leiden aanpassingen ertoe dat nieuwe Liferay patches niet eenvoudigweg
over de oude geïnstalleerd kunnen worden. Dit gegeven was één van de overwegingen om
vooralsnog geen aanpassingen in de source aan te brengen.
Stabiliteit en performance van het platform
De stabiliteit van het platform in de gekozen configuratie is zeer groot. Gedurende een
periode van 6 maanden is het platform niet eenmaal zelf down gegaan noch heeft het voor
conflicten gezorgd met andere servers.
Hoewel er geen performancetest hebben plaats gevonden, kunnen we aannemen dat dit
pakket lage hardware eisen heeft om goed te draaien. Naarmate het aantal gebruikte portlets
en plug-in’s toeneemt zal dit wel gecompenseerd moeten worden door extra hardware, vooral
geheugen is dan een belangrijke factor.
Gebruikersondersteuning
Vanuit technisch vlak is er weinig ondersteuning nodig voor de gebruikers. Wel is er
aanzienlijke tijd besteed aan ondersteuning van de hubtrekkers. Liferay biedt weliswaar
handboeken, maar deze werden als te uitgebreid en te ingewikkeld in geschat. Wij hebben
dus een eigen specifieke handleiding geschreven. Ook deze bleek nog vrij ingewikkeld voor de
meeste gebruikers, hoewel een en ander wellicht ook is terug te voeren op de geringe
hoeveelheid tijd die de gebruikers namen om zich vertrouwd te maken met de omgeving.
De meeste tijd is besteed aan de Hubtrekkers. Voor de eindgebruikers bleek de functionaliteit
dusdanig intuïtief dat zij snel genoeg aan de slag konden. De Hubtrekkers daarentegen, die
hun eigen collaboratories moeten beheren (gebruikers aanmaken, rechten zetten, teksten
maken, pagina’s aanmaken en die linken aan al bestaande pagina’s, enz.) zagen zich
geconfronteerd met een steile leercurve.
Aangezien wij in de beginperiode van de pilot ook nog gehinderd werden door twee zeer
vervelende bugs heeft het enige tijd gekost voordat de Hubtrekkers het pakket enigszins eigen
hadden gemaakt.
77
Appendix 5 Questionnaire User satisfaction
May 2008
Please describe your judgement and provide a numerical indication as well:
1=insufficient; 2=weak but sufficient 3=good
Please indicate also the judgement of the members of your collaboratory
1. Signing-in of new members
Currently, members are admitted first on the general list of users of the portal. Either they
can do this themselves or the administrators sign them on. Subsequently, they can request
permission to join a collaboratory, or the administrator can do so beforehand.
Judgement:
Valuation:
2. Functionality with respect to rights
The default rights structure is as follows: administrators have all rights on all files as well as
all portlets
The members, on the other hand, can only modify or remove their own files. They can only
add new structures to folder and forums within the settings created by the administrators.
Judgement:
Valuation:
Administrators can change the default rights (view, down- and upload) of the members.
This goes via update associations /update permissions, but it has to be done for each folder or
document separately.
Judgement:
Valuation:
Users of the private pages of the platform can only set rights on their own documents or
folders.
Judgement:
Valuation:
3. Document management
Liferay allows you to create folders, to up- and dowload files, documents and inages, to make
annotations and to manage versions. How do you valuate these functions?
Administrator:
Judgement:
78
Valuation:
Users:
Judgement:
Valuation:
4. Search facilities
In the Liferay platform, we have installed several search functionalities:
-
On (text in) documents,
-
on (content of) messages,
on users.
Do they meet your requirements?
Administrator:
Judgement:
Valuation:
Gebruikers:
Judgement:
Valuation:
5. Metadata
Relatively few metadata are attached to documents and files: documentname, version, size,
and file format. Are you satisfied with this functionality or should it be extended?
Administrator:
Judgement:
Valuation:
Gebruikers:
Judgement:
Valuation:
6. Communication
The communication tools are essential for a collaborory platform. Because integration with
the email system is currently not possible, communication, and to some extent out-bound
mail as well, operates through the forum and the option to comments on separate pages.
What is your opinion on these options?
Administrator:
79
Judgement:
Valuation:
Gebruikers:
Judgement:
Valuation:
7.Calendar
On the page ‘events’ a calendar has been installed. Is this useful?
Administrator:
Judgement:
Valuation:
Users:
8. Content management website
As administrators you can extend your own webpages, change the content, add images and
links et cetera.
Administrator:
Judgement:
Valuation:
9. General functionality
The platforms allows you to add new portlets. Have you done this? Have you missed specific
functionality during the actual test?
10. Ease of use
An important criterion for the choice of a platform has been ease of use: clear buttons,
intuitive design of the site, good explanation where necessary. In short: the ‘look and feel’.
Administrator:
Judgement:
Valuation:
Users:
11. ‘Helpdesk’
Frans and Lucien are subscribers to the category Guest>private pages>make feature request
and report bugs in order to respond to questions and problems. Has this worked well and
80
should it be continued? A user guide can be found on the messageboard. Is the guide
satisfactory? What points deserve more attention?
Administrator:
Judgement:
Valuation:
81