Towards online collaboratories for global data gathering in social and economic history

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 <
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