Although scientific writing plays a central role in the communication of clinical research findings and consumes a significant amount of time from clinical researchers, few Web applications have been designed to systematically improve the writing process.
This application had as its main objective the separation of the multiple tasks associated with scientific writing into smaller components. It was also aimed at providing a mechanism where sections of the manuscript (text blocks) could be assigned to different specialists. Manuscript Architect was built using Java language in conjunction with the classic lifecycle development method. The interface was designed for simplicity and economy of movements. Manuscripts are divided into multiple text blocks that can be assigned to different co-authors by the first author. Each text block contains notes to guide co-authors regarding the central focus of each text block, previous examples, and an additional field for translation when the initial text is written in a language different from the one used by the target journal. Usability was evaluated using formal usability tests and field observations.
The application presented excellent usability and integration with the regular writing habits of experienced researchers. Workshops were developed to train novice researchers, presenting an accelerated learning curve. The application has been used in over 20 different scientific articles and grant proposals.
The current version of Manuscript Architect has proven to be very useful in the writing of multiple scientific texts, suggesting that virtual writing by interdisciplinary groups is an effective manner of scientific writing when interdisciplinary work is required.
Any reader of the scientific medical literature knows that research prose is a very specialized use of language, distant from the general intellectual prose. Unlike writing in the humanities, the single most important function of scientific writing is the transfer of exact information and explicitly stated ideas. The writer of scientific reports attempts to convey the most precise meaning, in a logically coherent order, and in as few words as possible. Despite the obvious importance and distinction of the scientific writing when compared to other types of writing, no previous articles have described software solutions specifically designed to facilitate the process of manuscript writing (scientific articles and grant proposals) in virtual interdisciplinary groups.
The fundamental purpose of scientific discourse is not only the presentation of information, but rather its communication. It does not matter how well authors might regard their own writing; what really matters is whether the large majority of the audience understands what the authors wanted to communicate. Achieving simplicity in research texts is a complex task, the failure to write the final manuscript being one of the most common reasons for completed research projects not being published in peer-review journals [1,2]. The reason for this complexity is usually misunderstood. Most people assume that the difficulties in scientific writing are inherent to the scientific concepts, data, and analysis. However, Gopen  has argued that complexity of thought does not necessarily lead to a difficult text. In our manuscript, we argue that a software solution may assist researchers in simplifying this task.
It has been shown that information is interpreted more easily and more uniformly if it is placed where most readers expect to find it . These needs and expectations of readers affect the interpretation not only of tables and illustrations but also of the text itself. Scientific readers have relatively fixed expectations about where in the text structure of scientific manuscripts they will encounter particular concepts. If writers can become consciously aware of these locations, they can better control the degrees of recognition and emphasis a reader will give to the various pieces of information being presented.
Experienced researchers are aware of these expectations, but this skill is acquired usually after many failed attempts to learn the "unwritten rules" of scientific writing, which usually go far beyond the common IMRaD guidelines . This underlying concept of reader expectation is perhaps most immediately evident at the level of the largest units of discourse, a unit of discourse being defined as anything with a beginning and an end (e.g., a clause, a sentence, a section, an article, etc.). A research article, for example, is generally divided into recognizable sections, sometimes labeled Introduction, Methods, Results and Discussion. When the sections are confused in situations where too much experimental detail is found in the Results section, or when discussion and results are mixed together, readers are often equally confused. If these structural expectations are continually violated, readers are forced to spend a considerable amount of effort to understand its structure, taking time way from simply understanding the underlying message. In our article, we argue that a software solution might assist researchers in meeting readers' expectations in terms of text structure and its order, therefore substantially improving the final transmission of information.
Existing approaches: To our knowledge, no previous applications have explored the ability to use a Web application to allow interdisciplinary virtual groups to work synchronously and asynchronously on the same manuscript. Currently, word processors are the most common tools used for scientific writing. Also more formally known as document preparation systems, word processors are computer applications used for the production (including composition, editing, formatting, and possibly printing) of any sort of viewable or printed material. Word processing was one of the earliest applications for the personal computer in office productivity, prior to the widespread use of the World Wide Web. Therefore, the text content is most often stored in local computers and then exchanged through e-mails. Although electronic files are efficient for texts produced by single writers, interdisciplinary collaborations require more sophisticated exchange systems.
The objective of this article is to describe the Web application Manuscript Architect, designed to assist virtual interdisciplinary groups in the writing of scientific manuscripts (research papers or grant proposals).
The primary goal of the Manuscript Architect application is to simplify the process of scientific writing. Manuscript Architect divides the writing process into the following steps: (1) list main concepts (text blocks), (2) establish hierarchical order of text blocks, (3) connect text blocks, (4) ensure consistency across text blocks, (5) use previous examples of text blocks with a similar focus, (6) facilitate the translation when manuscripts are not written in the language used by the target audience (readers and journals).
The overall objective of the Manuscript Architect project was to build a Web-based tool that would allow virtual groups to work on scientific manuscripts using synchronous and asynchronous methods. Before designing the application, we analyzed similar target applications in a diverse set of domains, including project management tools, text editors, tools for voice communication, and software tools for sharing of computer screens. Our search can be summarized into the following list of technical requirements that would be highly desirable for the application:
• Hierarchical navigation of text blocks, allowing authors to easily locate their current block within the entire manuscript. The concept of text blocks has been previously described by linguists such as Hoey . A text block is a unit of text with a single focused content. In the Manuscript Architect application, we use the term text block to refer to a large unit of text, not necessarily related to the linguistic concept of text block. Similar approaches have been used by other applications such TuxCards .
• Fast screen upload for easy transition between text blocks
• Block text saving diversified among multiple application activities to avoid loss of text
• Primary author should be able to assign text blocks to co-authors and track their progress
• A full view of the manuscript should be available, displaying subsections as required
• Print to PDF or easy transference to commonly used electronic formats
• Word count by block texts and groups of block texts (e.g., abstract)
• Automated e-mails when a text block is assigned
• Color coding to identify the status of text blocks. For example, it should be clear for co-authors which text sections have been assigned to them and which sections have been completed
• Support for insertion of hyperlinks, figures, and other electronic files
• Robust security
• Scalability in the associated management system, including full compatibility with our existing project management application Research Manager
The Web application we have implemented to date meets all of these requirements. Other requirements will be met in our planned enhancements, as described in the Conclusion section below.
Software architecture for Manuscript Architect: The language of choice for the application development was JAVA, since it facilitates the integration of the Manuscript Architect application with the other existing applications in our suite . We chose the classic life cycle development method , which includes the following steps: (1) the analysis and specification of pre-requisites using prototyping methods, (2) project, (3) implementation and unit testing, (4) system integration and testing, and (5) operation and maintenance.
The Manuscript Architect application works integrated with Research Manager, an application developed by our group for project management . As the user logs into Research Manager, the first screen of Research Manager (Figure 3) displays a list of manuscripts named "My Manuscripts". This list represents all manuscripts where the user is either the primary author or has at least one text block assigned to her/him. Having the name of the manuscript listed under "My Manuscripts" serves as a reminder that a writing task is to be performed in that manuscript. Once all text blocks assigned to the co-author are completed, the manuscript name no longer appears in the "My Manuscripts" list. It can, however, be accessed by co-authors through the Research Manager screen available for individual projects (Figure 4). Only project participants have password-protected access to the manuscript. If the manuscript is accessed either by the "My Manuscripts" list or directly through the project itself, the interface page for Manuscript Architect is the same (Figure 5).
Figure 3. Manuscript Architect interface.
Figure 4. Manuscript Architect interface.
Figure 5. Manuscript Architect interface.
The interface of Manuscript Architect is divided into two separate portions. The left portion of the screen contains a hierarchical tree with all text blocks displayed in order of appearance. The hierarchical level is represented by the left indentation. In other words, a text block of level two is contained within the text block of level one right above it. The entire manuscript is contained under the root level. Text blocks where the user is currently working are highlighted in orange to facilitate identification. The title of each text block is identified by colors: red is a text block that has been assigned (the name of the assigned co-author and date of assignment appearing on the right side of the text block title; green is a text block that has been returned from a co-author to the primary author, and blue is a text block that has been marked as completed by the primary author. A button below the hierarchical tree assembles all text blocks into a single document, displayed on the right side of the screen.
The right portion of the Manuscript Architect application can display two types of screens. First, when the user has ownership over the text block, the block is editable and the window can be used as a regular word processor. A list of available editing tools include the ability to turn the title of the text block into a heading in the final manuscript, font size, bullets, numbered items, bold/italics/underlined, text alignment, table insertion, link insertion, and file insertion. Inserted pictures are displayed directly on the screen. Links to files, such as full-text documents, are displayed as hyperlinks. At the bottom of the screen a drop box allows the primary author to assign the text block to individual co-authors, save or remove the text block, and mark the text block as completed. Co-authors only have the save and completed options. Of importance, the text block is saved every time the user moves from one block to another. When the user does not have ownership of the text block, the right portion of the screen will be visible with read-only privileges. Primary authors have the ability to revoke the text block if necessary.
Usability was evaluated at two distinct levels: (1) Formal usability analysis and (2) field observations. Formal usability analysis was conducted with ten different users with no previous experience with the Manuscript Architect. Five users had previous experience with scientific writing, while five were novice researchers.
Formal usability tests  followed a protocol where users were observed by one evaluator (RP) and had to complete scientific writing using the notes and previous examples. Users were free to ask questions at any point in time. Tasks included the writing of different portions of scientific articles, assigning different text blocks to different users, count words, observe the document in full-view, recover text blocks that had been initially assigned, insert links, insert documents (pdf files), and change font and alignment characteristics. Each participant answered a questionnaire at the end of the formal usability analysis with items about interface problems, missing features, and suggestions for overall improvement.
Field observations were comprised by observation of researchers using Manuscript Architect for the writing of scientific articles during an online writing workshop where over twenty different manuscripts were being written at the time by 14 different researchers (for a current list, please refer to http://www.ceso.duke.edu/servlet/URMController webcite). Junior researchers include medical students, graduate students, residents, fellows, and junior faculty. During these workshops, Manuscript Architect is coupled with Voice over the Internet Protocol (VoIP) applications. Most of the manuscripts include co-authors from different disciplines located in at Duke University as well as other academic institutions in the U.S. and abroad. Similar to the formal usability tests, the evaluator (RP) took notes of problems encountered during the writing session regarding interface, missing features, and overall suggestions.