For the rest of this year I'm using Drupal's book module for a substantial collaborative research document (250,000 words, 50 authors, 130 peer reviewers). This is a useful project to test Drupal's ability as an academic authoring tool, and I will document some experiences as I go along, hopefully working towards a longer howto article for later publication (and perhaps a collaborative authoring branch of drupal-on-a-stick).

general comments
--> for those working in a windows environment, particularly when working with technophobe colleagues, the drupal-on-a-stick project is fantastic (http://www.ratatosk.net/software/onastick) and encourages people to try out drupal at home

--> for new users, it's worth buying one of the Drupal books as a desktop reference.

--> the process of choosing, installing and relevant modules takes time. While it makes sense to keep Drupal core simple and to encourage the plug-in process, Drupal.org should perhaps begin a series of 'use cases' or 'kickstart lists' to get users up-and-running quicker (e.g. 'drupal for academic authoring', 'drupal for media content', 'drupal for media screening', 'drupal for magazines')

drupal for academic authoring - kickstart list

For academic authoring, the list of relevant (non-core) modules is as follows:

book (tip: under admin/settings/content types, switch on 'Create New Revision' )
contact
collapsiblock
dba (database administration)
diff (the patched version - see comments below)
excerpt
export_docbook
forum
glossary
linenumbers (needs some improvement for peer reviewing/comment response, but a decent start)
locale (for customising interface text without messing about with module code)
masquerade
jstools
nicemenus
path
sidecontent (tip: style the sidecontent block to look like post-it note for reviewers )
tinymce (tip: educate users on the 'toggle to fullscreen' button)

In addition to this module list:
marvin (chameleon) theme: clean and very white (suitable for editing publications) -- you'll need a lot of screenspace, so consider removing logos/primary/secondary links sections from the template

If your audience includes speakers of other languages, the machine translation block is a simple way to
facilitate gist translations: see http://www.digitalraindrop.com/Drupal-CivicSpace-Translations

bibliography module: this should soon be available - http://drupal.org/project/biblio

shoutbox (and in the future, better integration of phpfreechat) is useful for basic communication with authors: the phpfreechat will in particular be useful for scheduling virtual meetings about chapters/articles

glossary2 is useful, but lacks the the filtering offered by the basic glossary module; a full dictionary module (multiple definitions, multi-language equivalents, citations, concordance info, etc.) would be helpful for the drupal project.

linenumbers -- for peer review (that is, enabling comment on nodes and not edits) the linenumbers module is a useful way to cross-reference comments with node content without changing its base content -- ideally, this module will be improved to add links on linemodule's paragraph ref. numbers to open a comment that is prepopulated with (i) the paragraph ref. number and (ii) the content of the paragraph with quotes

The Collaborative Editing project currently in the Summer of Code 2006 is likely to help authors work concurrently on the same chapter; while synchronous/Ajax reporting is a little too 'realtime' for most academic publications (they typically have a production cycle where authors work on a document in separate sessions), why not raise the bar for collaborative editing with Drupal?

My experiences so far:

diff
The diff module is essential for collaborative editing, but needs work. It could benefit from:
(i) a full 4.7 release (catinthehat's patch integrated into core)
(ii) update to the latest diff features within the PEAR library
(iiii) features to 'rewind/forward' views of revisions over time
--> see http://phiffer.org/projects/wikipedia-animate and http://ejohn.org/projects/aniwiki/
(iv) .css styling to highlight additions/deletions/changes in a richer way (with graphics)

-- I know it's peanuts, but I would put up a bounty of $100 to see all these features (particularly item (iii), which oozes geek cool) implemented into Drupal's diff module. A few other similar contributions and we might have enough to make this happen.

taxonomy administration
--> add term - adding terms manually is time consuming: could we build a shortcut way to upload multiple terms (for example, using txt files with new lines and hyphens to indicate parent/child relationships)? This can currently be done using free tagging, or using an xml-based taxonomy import, but adding several terms in a single submit direct using admin/categories/add/term would be great.
--> list terms - I would like to see a possibility to delete (with confirm, naturally) or rename multiple terms on this page (without proceeding to a new edit page)

permission settings and general admin interface
-- setting up individual users and permissions with the taxonomy access module is time-consuming and onerous
--> any way to improve the admin interface of taxonomy access is welcome
----> in particular, any js widgets to select/deselect all radio buttons throughout a column in a page
----> enabling admin control over paging and the number of rows listed on a page would be helpful
----> how about some kind of 'duplicate role' function would help speed up the process of creating roles with similar (but not identical) access permissions?
----> on the url alias list, it would be useful to be able to edit/rename multiple aliases in a single submit

text-based buttons and links
--> in order to beautify the interface and user experience, it would be good to be able to replace text links with graphical buttons (perhaps using the tango project for many of these icons)
--> could the locale module be tweaked to enable the replacement of text strings with images?

tinymce save button
--> As most authors are used to MSWord, the interface is generally similar and easy-to-use. However, there is a tendency for users to be lazy, and to associate tinymce's HTML 'update' button with saving/submitting the document into drupal, or just to open a new browser window, get sidetracked and forget that there is no autosave feature if they inadvertently close the browser. Adding a save button on the TinyMCE toolbar (which submits the form) is the solution: see -
http://sourceforge.net/tracker/index.php?func=detail&aid=1091350&group_i...

Comments

msebold’s picture

thank you for starting this topic -- it's one of the key considerations in our decisions on how to deliver an effective online community environment. being a newbie (and what i call a pseudo-techie), i have yet to acquire a useful degree of understanding, but i would like to ask you about an opinion given in a web design blog: that the category module has rendered both the taxonomy, and book modules obsolete (http://www.nicklewis.org/node/851). assuming the author's assertion is valid, how (if at all) would this affect your guidance and comments here?

peteThomas’s picture

I'm not too familiar with the category module -- all I know is that on a fork test site it broke the taxonomy/book structure I had previously worked on. As far as I am aware, the category module is a side-project which co-exists with Drupal development but where compatibility/release issues may be an issue.

That said, I did not explore it too much and would appreciate any input you have.

I'm trying to stick as close to the book and taxonomy modules as possible, largely because the Taxonomy Access module offers good control over what different authors/reviewers/editors can and cannot do. My experience is that it's time consuming to set up the permissions grid and to use a taxonomy term as a 'lock' for a page or chapter. I also like the taxonomy export/import features... rather than going through the taxonomy module's native 'term-by-term' way of building a taxonomy.

sepeck’s picture

You may want to touch base with the folks on http://drupaled.org/ as well.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

peteThomas’s picture

The project for this research publication is proceeding well, and I'm getting useful feedback from users.

Note that the EU is investing seriously in academic library projects under the eContentPlus programme.
-- http://europa.eu.int/econtentplus. If anyone reading this post is currently involved in Drupal for libraries/bibliographies, funding is worth investigating.

bibliography
- the released bibliography module is excellent (particularly the endnote integration), but has been developed for 4.6 not 4.7;
- over the coming weeks I expect to build and test a patch for 4.7 (currently buggy on a test site)
--> an additional wish is to enable citations within book pages that both (i) link intra-node citations to the general biblio and (ii) can be pulled in as footnote 'sub-bibliographies' at the bottom of a book node (likely to be accomplished with a PHP snippet).

open search
To add to the list of modules, the new Opensearch module is useful, particularly given the take-up of the format by academic libraries (PubMed, etc.).
There are numerous possibilities with Drupal for building a more generic academic research portal - complete with RSS feeds, collective bibliographies, online meetings/webinars (esp. via the skype support module)... and with this new module automated grabbing of emerging research - but I will restrict this thread to the use case production of a single journal.

Author support (e.g. for content tagging)
Naturally, all content benefits from the use of metadata, spellcheckers and tools to help the authors write better prose. One service I've been recommended (by former contacts in the translation industry) is http://textalyser.net. It provides keyword occurrence and density/readability stats, etc. -- these stats can help authors better choose tagging keywords.

-- I am considering enabling direct submission of content to textalyser.net via (i) a TinyMCE toolbar button and (ii) a node link (to be placed alongside the print-friendly link on nodes).
--> if anyone can suggest a more 'embedded' way of integrating textalyser, let me know.

Machine gist translation
The block level machine translation snippet seems to have disappeared at digital raindrop. I will post a suitable snippet on drupal.org if it does not reappear soon.

General user feedback
There has naturally been some resistance from users who are used to commenting/track changes in Word

-- One useful tip for users is to encourage them to use the upload module: this enables the more stubborn users to work in word regardless -- but it kind-of defeats the object for multiple peer review.
--> One of the key objections is that comments are threaded (or, less kindly, 'dumped) at the bottom of a node, avoiding the right-hand of page marginalia academics are so fond of. I'm thinking of ways to mimic this comment paradigm using Drupal, but the hacks are likely to be horrible.

There have been some comments on how to better display tabular data (zebra tables, etc.) within nodes, and also to enable direct editing of charts (users have been so far using graphic dumps from excel/word). PHP/SWF Chart integration would appear to be a good solution, but the javascript/chart field is currently producing useful code (see http://webfx.eae.net/dhtml/chart/chart.html)

peteThomas’s picture

The publishing project is ongoing.

Usability of online editing -- towards a wiki
General feedback on TinyMCE-based editing is that people prefer olde worlde Word editing. There are some performance issues for larger documents. In particular the revisions/track changes feature (the diff module only gets moderately close). So, I advise to work with word and attachments on drafts and work-in-progress, with a shift to the online tool as a project comes closer to publication.

-- One learning experience is that, with longer documents (over 1600 words, 6-7 scrolls), there seems to be an upper limit for the 'chunk size' for successful online editing (about 200-300 words... anything over 50% of screen-height is getting too long).

-- Rather than splitting content across multiple book pages... likely to complicate matters further... I am looking at how Drupal progress on wikis might facilitate 'wikipedia-like' paragraph-level editing/commenting, together with edit histories.
See: http://drupal.org/node/102913 and the http://groups.drupal.org/wiki

eLibrary and Bibliography concerns
It is great to see the bibliography module progress from a basic Bibtex tool to becoming a strong open source contender to rival wikindx's features. The additional power of drupal -- taxonomy, plugin ontologies (relationship module), chatrooms, forums, polls, news aggregation, opensearch aggregation, versioning, multimedia libraries -- might make Drupal into a highly attractive framework for building e-libraries.

For my project, the open source reference manager Jabref is a godsend -- a fast, powerful way to ensure authors are able to share bibliographies. The import objects in Jabref could be used to scour a bibtex dump from the biblio module... a great twinning of (java) client with (drupal) server.
http://jabref.sourceforge.net

Interesting to watch the drupal library project at:
http://drupalib.interoperating.info/node/29

And also to scour a couple of great open source librarian blogs:
http://onebiglibrary.net/geeks
http://bonariabiancu.wordpress.com/

Parallel-language glossary/taxonomy
One need (or feature request) that has arisen is to enable the tagging of nodes via a multilingual taxonomy (that is, a taxonomy which exists in multiple translated versions -- the taxonomy in question is at hpmulti.net). This need implies some kind of switchable multilanguage taxonomy, outlined at http://drupal.org/node/39569.

Search by taxonomy term and cool ajax search refining
The free tagging module already offers some great predictive text data entry.
One item that could help searches on Drupal (especially in library environments) is to encourage structures searches (using a taxonomy).
There are some search parameters for building a custom search module at:
http://api.drupal.org/api/4.7/function/hook_search

However, to refine searches using a (free tagging-like) AJAX taxonomy lookup would be cool. See (a non-Drupal) use of this at:
http://www.bireme.br/php/index.php?lang=en

rojgars’s picture

Data entry jobs free tagging module already offers some great predictive text data entry.
Data entry jobs that could help searches on http://drupal.org/(especially in library environments) is to encourage structures searches. Some search parameters for building a custom search module.

bomarmonk’s picture

There is a plugin for Moodle and standalone project called marginalia that can be found here:

http://www.geof.net/code/annotation/download

arindamghatak794’s picture

Hi there!

Since you mentioned that you have 50 authors and 130 peer reviewers etc, I was wondering how do they export their books into acceptable formats like word or pdf ? Because, as I see it, without that facility, their books will always remain just online!

Thanks,
Arindam

peteThomas’s picture

Hi --

-- For pdf export, try pdfview, although read the info/problems with larger books at: http://drupal.org/node/97859

-- Openbook export is relatively easy, but for digital-to-print, a Quark/InDesign process is still in my view necessary to obtain a trylu professional print publication.

-- As mentioned above, for early stage work I have found authors to be much more comfortable with word attachments to book pages. When a 'near-final' version is ready (review/tweaking phase) the online editing tool is more useful.

-- For my project, the online editing process results in a manuscript which then enters a standard DTP/proofing process. I advocate that, for print editions, a basic export from digital to printable will always benefit from professional intervention (style guide, paging, indexing, etc.).

Pete

lejon’s picture

Don't know if you have the time, but I'd be interested in knowing how you exported from Drupal into Indesign. The XML I've exported from Drupal shows up in Indesign with the paragraph and other formatting marks included in the text.

I'm working on staff handbooks for NGOs and want to use Drupal as a collaborative writing tool.

Thanks for this article - it's very interesting and exactly what I needed.

drupalista’s picture

I am also very interested in the process of using drupal to collaboratively write articles and books and importing them into InDesign - would be good to open a new thread on this topic, I think? Are there any experiences with this process?

You might be interested in this article:
http://tomster.org/blog/archive/2005/03/01/plonearticle-to-indesign

lejon’s picture

Might be worth opening up a new group on this subject. I am already in the 'annotate module' group http://groups.drupal.org/annotate-module which is closely related...

do you want to open one up and manage it??!

mbria’s picture

During last weeks I have been building some webs for different research groups of my department.

I'm playing with drupal multisite features (single code, single interface translations, single content types) so I started what I expect to publish as "table-cloner" that allows to replicate some of a main site tables between the new instances (multisite and others don't fit with my requirements).

Any case, back to the thread of this discussion, those sites include the following features:

FOR VISITORS:

* Multilang: (i18n) We need to publish some node types (page, story, events, books) in different languages. i18n is great for this and I'm still unable to understand why it wasn't included in drupal 5.x core. Any way, interface is translated by drupal's core "localize".

* Staff: (profile) Listing based on a "visible" hidden check box to avoid Admin, or other "non-researchers" users to be listed and some personalization adding profile fields and templating (for instance, linking to "project nodes")

* Projects: (cck + views) cck-userfiled let me relate projects and members. I use cck-taxonomy fields to create "open taxonomies" (folkonomies) to define the "granters", finally cck-date let us define the project's period. Views list it all in a sortable table.

* Publications: (biblio) I'm still impressed about biblio module. Just extended with "upload" core module and patched a little to work fine with i18n was exactly what I needed.

* Documents (??) I'm unsure what to do here. Joomla includes Docman, but in drupal we didn't have a real DMS system as good as "Owl intranet" so forgetting owl, looking for full integration I'm playing with two different approaches: webFM or CCK based dms. webFM is really good but I will need to extend to include "check in/out", "zip folder", "file versions" or other important dms features and don't forget that files aren't nodes so I'm unsure. By the other side, creating my own cck node (with upload or cck-filefiled) to implement a new "document" node will be more flexible, but looks like work will be harder to adapt in the interface part to something as fast as webFM. Any case, this second approach is also compatible with e-swish indexer or markj's search_attachments module (http://drupal.org/project/search_attachments). I found tones of discussions about Drupal as a DMS so I expect something will be developed soon... but any suggestion is welcomed.

* Events (event) Nothing special here because "event" offers the collaborative calendar (with ical and RSS) I wanted, powered by drupal's taxonomies and i18n translation of nodes. The only work required was translating the interface and some css to fit the global look&feel.

* Web links (weblinks) weblinks module as is, to let every research group construct and share links they find interesting with their audience.

* Contact (contact) as is or better combined with captcha.

FOR MEMBERS:

* Simple Panel (snippet) I created my own snippet to simplify the content administration to some basic. Visual frontend makes users' life easier ;-) Every box manages different nodes and little icons let you browse (a single view with node type as an argument) and add new ones (link to /node/add/%type). Consistent interface don't let include much details but learning curve decreases a lot. Here you have a screenshoot http://psicologiasocial.uab.es/base/es/system/files/simple_panel.png (sorry but some parts still need to be translated)

* News and Events (story and event) combined with i18n to allow different content on different languages.

* Forum (forum) as is in drupal core. Very simplistic, but does the job.

* Web pages (Page) to allow the collaborative construction of the site and combined so with "menu" and "path".

* Blogs (blog) just a little tunning on blog node themes and folkonomy (free taxonomy) to combine with "tagadelic" module.

* Books (book) There was a nice wiki filter that allows "mediawiki" syntax and so on, but finally I realize that books does the same work and looks simpler. Obviusly tinyMCE was needed and IMCE was the perfect companion. BTW, to simplify every node type (hiding options to some roles) I found that "formfilter" is extremely useful. Finally I didn't enable "outline" in non book nodes to avoid confusions.
Books nodes also include "revision" by default, "upload" and "diff" feature, exactly as you commented in your post and following your suggestions I will include "export_doc_book". Nice we arrive to similar points without been in contact... it means we are in the right way !! :-P

* Printing (printerfriendly) showing plain information was important for my fellows and works specially fine in combination with Books module. May be I also include "pdf" output.

Just to close a couple of details:

Roles are really important in my case so I can delegate the site to a member of the research group included in "Administrators" role (letting them to change themes -btw, garland-color is great to personalize-, blocks, user administration...) and he or they can delegate again in "Editors" with privileges to extend the site with new pages and also create users. Finally "authenticated users" are the research members that I expect will use the site to collaborate and share information, but not much worried in the group's dissemination.

By the other side I'm thinking seriously in Taxonomy Access or similar to let my users decide what content will be visible for external users or not... although probably "Published" will be enough for this.

I'm missing a lot of stuff but my personal conclusion is clear: Drupal is an impressive beast !! Flexible enough for quite everything, but tame it takes time. To develop this web site it took me quite a month, including testing tones of modules and making tests.

I will reduce this developing time to half if every module include a demo (like in joomla) and better documented... but I sill love drupal, code is clean and clear and it's architecture is a beauty.

I use drupal as a framework for quite everything, except Learning Management Systems (try moodle!), e-Journals (try OJS !!) and conferences (try OCS).

chlobe’s picture

some very good recipes in here

I'm particularly interested in optimizing the best of breed OS triad of Drupal-OJS and OCS.

oyunindir’s picture

some very good recipes in here

I'm particularly interested in optimizing the best of breed OS triad of Drupal-OJS and OCS.

oyun indir

fernao’s picture

I'm making a research to choose an application in order to implement an E-journal.

Yes, OJS is very good, but, as a heavy drupal user, I've included it on my research. In just a few words, I've realized that there's a problem on OJS regarding it's architecture. It seemed a little bit monolithic, but on Drupal, every task should be implemented manually.

If anyone has any advances on the topic please post it here!

Fernão