University of ManchesterSchool of Computer Science

Project Report

Text Editor for Scholarly Writing

Author: Liam Breeze

Supervisor: Dr. S. Pettifer

May 3, 2016

Abstract

Text Editor for Scholarly Writing

Author: Liam Breeze

Despite the Internet’s reduction to the cost of distributing scholarly articles, the processof publishing such documents is still costly. One cause of this cost is the difficulty ofprocessing authors manuscripts into a publishable papers, a task mostly done manually.The issue with this is that a majority of academics use tools such as Microsoft Word,which produce files which are difficult for computers to process.This project’s goals are alleviate this cost by producing a word processing tool whichproduces machine readable files. Primarily focussing on the production of XML filescommonly used in the publishing industry. Other targets are the simplification of cita-tion and avoiding unnecessary functionality. These offer greater value for prospectiveusers and promote uptake of the tool.

Supervisor: Dr. S. Pettifer

Acknowledgements

I would like to thank my supervisor, Dr. Steve Pettifer for all the guid-ance throughout my degree and my girlfriend Natalie Brown for managingto deal with my stressful self.

1

Contents

1 Context 51.1 Scholarly Article Authoring . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 Publishing a Scholarly Article . . . . . . . . . . . . . . . . . . 61.2 Proposed Authoring Tool . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.2 The Targeted Machine Readable File format . . . . . . . . . . . 71.2.3 Citation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Analysis of Other Word Processors . . . . . . . . . . . . . . . . . . . . 91.3.1 Microsoft Word . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.2 LaTex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Development 112.1 Research and Requirements Gathering . . . . . . . . . . . . . . . . . . 11

2.1.1 Programming Language . . . . . . . . . . . . . . . . . . . . . 112.1.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 Requirements Gathering . . . . . . . . . . . . . . . . . . . . . 13

2.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Machine Readable File Format . . . . . . . . . . . . . . . . . . 142.2.3 Semi-Automated Citation . . . . . . . . . . . . . . . . . . . . 152.2.4 Document Representation . . . . . . . . . . . . . . . . . . . . 16

2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Machine Readable File Format . . . . . . . . . . . . . . . . . . 172.3.2 Semi-Automated Citation . . . . . . . . . . . . . . . . . . . . 182.3.3 Document Representation . . . . . . . . . . . . . . . . . . . . 182.3.4 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2

3 Evaluation 213.1 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Refactoring and Reflection . . . . . . . . . . . . . . . . . . . . 213.1.2 Test First Development . . . . . . . . . . . . . . . . . . . . . . 223.1.3 User Stories and Taskboards . . . . . . . . . . . . . . . . . . . 22

3.2 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.2 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . 243.2.3 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.4 Graphical User Interface Testing . . . . . . . . . . . . . . . . . 243.2.5 XML Validation . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Reflection and Conclusion 264.1 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1.2 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.3 Analysis of Positives and Negatives . . . . . . . . . . . . . . . 274.1.4 Identification of Knowledge Gained . . . . . . . . . . . . . . . 284.1.5 Future Considerations . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A Screenshots of Text Editing Tool 32

B QT5’s Testing Framework 35

C JATS XML Example File 36

D User Stories and Task-Board Images 38

3

List of Figures

1.1 A common pipeline for scholarly article publishing. . . . . . . . . . . . 6

2.1 System architecture diagram for the tool. . . . . . . . . . . . . . . . . . 142.2 Architecture diagram for reading and writing a document from/to a

JATS XML file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Architecture diagram for citation sub-system. . . . . . . . . . . . . . . 152.4 Partial layout of internal document representation. . . . . . . . . . . . . 162.5 UML diagram for file interaction sub-system. . . . . . . . . . . . . . . 172.6 UML diagram for Citation sub-system. . . . . . . . . . . . . . . . . . . 182.7 Partial UML diagram for the document representation sub-system. . . . 19

A.1 Screenshot of the tool with an example JATS XML file open. . . . . . . 32A.2 Screenshot of the tool acquiring an external reference. . . . . . . . . . . 33A.3 Resulting LaTex files after conversion from JATS XML. . . . . . . . . 34

B.1 Example test file utilising Qt’s QTest framework. . . . . . . . . . . . . 35

C.1 Example of JATS XML file: Top . . . . . . . . . . . . . . . . . . . . . 36C.2 Example of JATS XML file: Middle . . . . . . . . . . . . . . . . . . . 37C.3 Example of JATS XML file: Bottom . . . . . . . . . . . . . . . . . . . 37

D.1 User Story example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.2 User Story example 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.3 User Story example 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40D.4 Example of user stories utilised with taskboards. . . . . . . . . . . . . . 41

4

Chapter 1

Context

This report introduces the problems and achievements of my third year project.The project’s aims were to build a cross-platform word processor optimised for

scholarly writing. Providing only the functionality required to write papers. In orderto encourage the adoption of the tool, functionality simplifying the act of citing otherpapers and outputting of machine readable file formats was provided.

The motivation for providing such a tool is the large costs of publishing scholarlyarticles. Partly contributing to this cost is the requirement to typeset a manuscript intothe final paper. The driving force of this issue is the common use of tools such asMicrosoft Word in the majority of academia. This text editor allows the construction ofdocuments that are easy for humans to read but difficult for computers to process[17].

Upon reading this chapter the understanding of the project and it’s motivation shouldbe clear. To cover the context of this report, a subset of the issues concerning costs ofpublishing a scholarly documents are introduced. Following this a tool is proposedwhich attempts to solve these issues, which is to be developed as a part of the project.Analysis of other word processors are performed in order to provide a better understand-ing of what is required from the tool. Giving an insight into how these tools deal withthe issues discussed.

1.1 Scholarly Article AuthoringIn order to provide some reasoning as to the need of the tool built during this project,a brief introduction to a common interaction between scholarly document authors andpublishing bodies is provided. This discussion covers a very small layer of such aprocess, but is aimed at introducing a specific issue that could be solved during such aproject. Ultimately aiding the scientific community by alleviating costs for publishingscholarly articles.

5

1.1.1 Publishing a Scholarly ArticleAnyone who has experienced the process of publishing a scholarly document will attestto the issues of cost. Common publishing processes incur various costs which could beavoided by the adoption of more modern tools.

Initial Scholarly Article

Publisher Typesets Paper

Corrections

Typesetting of Corrections

Published

Figure 1.1: A common pipeline for scholarly article publishing.

Figure 1.1 illustrates a small aspect of a common publishing pipeline. The initialscholarly article stage is the situation where the manuscript is submitted by the authorto the publisher. Commonly this submission takes the form of a Microsoft Word file ora PDF; which are not machine readable. This is then typeset into a machine readableformat such as XML or LaTex, which is a costly process commonly outsourced to var-ious countries[23]. Achieving this involves human interaction, due to the complexityof processing information from such file formats. This process introduces errors anddiscontinuities from the original which require rectification. Amendment of these er-rors involve sending the new machine readable format of the document to the author forscrutiny. These corrections are then integrated into the document, producing the finalreport ready for circulation.

The cost of publishing scholarly articles varies wildly depending on the differingforms of publishing and the body associated with the author. The various modelsfor publishing scholarly documents include a subscription and open access based ap-proaches[8]. The costs vary depending on whether the author has backing from a bodysuch as a university which may have an agreement with the publishers to alleviate somecosts. Despite these situations the price of publishing a scholarly article lays withinthe price range of £150 to £5000[7, 9], with various circumstances altering this greatly.The cost incurred due to the need of typesetting is avoidable by providing tools whichproduce the final file format for the authors manuscript, prior to submission.

6

1.2 Proposed Authoring ToolFollowing is the outline for the tool which can solve the issues discussed in Section 1.1.Initially the scope of such a project is noted, followed by the ever important discussionover what file format to support. Subsequently features regarding citation are discussed,focusing largely on producing further value for users in the hopes of improving adoptionof the tool.

1.2.1 ScopeAn acceptable tool for scholarly article composition must come with functionality usersare accustomed to. Many such functionalities are found in tools like Microsoft Word,but are present in almost all text editors. A few worth highlighting include editing com-mands: cut, copy and paste. Following these the tool would require aiding the user infinding information within the file, reading from and writing to a file. Other aspectsof text editors require avoiding, not all commands are required in writing a scholarlyarticle. The features that alter semantics of the document are necessary, whereas othersmay be unnecessary. Text formatting commands such as bold, italic and underline arefrequently viewed in such documents, therefore they require inclusion. Whereas adjust-ing the font and text size are not required; such aspects will be discarded during theprocess of typesetting.

A successful tool requires additional features to be able to compete with competitors,distinguishing itself in the market to encourage its adoption. A clear piece of function-ality required is the reading and writing of machine readable text. This distinguishesthe goals of the tool but not enough for common adoption. Further functionality mustbe incorporated in order to provide value for the user. A common task during the com-position of scholarly documents is the citation of external papers. In order to alleviatethe work required by a user, the tool should provide functionality aiding them with thistask, having the search and inclusion of such citations integrated into the tool. A similarsystem should be adopted with regards to including authors to the document.

Certain features will require omission from the tool due to time constraints and com-plexity. Most subjects require the inclusion of figures and equations in their documents.Despite the clear value of such features, they must be left out of the scope to aid withcompleting the base tool.

1.2.2 The Targeted Machine Readable File formatThe decision of what machine readable format the tool will support initially is key to itssuccess. Benefiting the user through solving such problems as covered in Section 1.1.1.A decision to follow a file format rarely utilised in the publishing industry will stymie

7

the need for such a tool. This decision was made more difficult with the sheer numbermarkup languages available for document description.

LaTex is a commonly used markup language in Computer Science. Extensivelyused in producing scholarly documents in the subject area as well as in Mathematicsand Physics. This format is even accepted by some publishers as a machine readablefile format, alleviating a number of issues. Despite the large number of positives LaTexhas, there are a few downsides, most notable is the difficulty of using the language withno prior experience with similar languages.

The next logical step is to discuss what language a publishing body produce duringtypesetting of a manuscript. Commonly this formats is a flavour of XML known asJATS XML(Journal Article Tag Suite)[12]. Designed to describe and store documentsin a formal machine readable format, which has been widely adopted by publishers. Inthe typesetting of documents discussed in section 1.1.1, this will the machine readableformat produced in many cases. Appendix C displays an example JATS XML file.

There exist tools allowing the conversion from common markup languages to JATSXML. This allows the tool to support a number of common markup languages and stillproduce the file format a publisher would require. Among these tools Pandoc[16] is themost appealing, being easy to use, open-source and supporting a myriad of file formatssuch as Markdown[14] and HTML. This lead to a new thought process, why not supportJATS XML directly. This will allow for greater control over the final document by theauthor, avoiding automated decision making during the translation process. UtilisingPandoc can then produce the other file formats, providing the user with options as to thepaper format.

1.2.3 CitationFunctionality in order to aid with citation will be a key selling point of such a tool. Thefunctionality should be an integrated search and inclusion of external references, suchthat the user may cite a paper without the use of a web browser.

The inclusion of references will need to autonomously obtain all the required dataand format itself in the way an user is accustomed to. This decision deviates from theargument of avoiding formatting functionality in Section 1.2.1. This is due to the na-ture of the targeted users, who will commonly concern themselves with such formattingduring the composition of scholarly documents. Instead of fighting the user in order toenlighten them as to the lack of necessity of such concerns, the tool will accommodatethem. In order to achieve this a database of scholarly documents will require consul-tation. CrossRef[6] is such a database which is easily utilised. Alternatives includeDataCite[1], which provides a similar search capability but lacks the simplicity of useCrossRef provides through their simple to use RESTful API.

8

1.3 Analysis of Other Word ProcessorsIn order to aid with designing the tool which overcomes the issues outlined in Section1.1.1 a brief analysis of current word processors for scholarly article composition isperformed. This analysis covers the extremely popular Microsoft Word, followed bythe Computer Scientist’s favourite LaTex.

1.3.1 Microsoft WordMicrosoft word has been the most popular text editor for composing many document,this includes many scholarly documents. There is a reason behind this, primarily thiscan be attributed to the long history of use and the easy to comprehend interface1. Thequestion is whether a tool can compete with such a popular text editor, is any other tooleven necessary?

What the proposed tool achieves that differs from Microsoft’s Word is to target aspecific subset of users. Allowing the interface and functionality to be tailored to suchindividuals and providing greater value for them. The file format produced is also a keydifference. Microsoft Word’s document format is similar to a PDF, wherein the wordsare ‘painted’ onto the page with formatting. Providing simple to read documents forhumans, aggravating the issues of Section 1.1.1.

1.3.2 LaTexLaTex is the markup language highly popular with Computer Scientists, including thisauthor. With a myriad of positives to it’s capabilities and the production of machinereadable files the language sounds ideal for scholarly document composition, whicharguably it is. Despite this the language has a large flaw, the requirement of learning alarge amount of it’s syntax. For those accustomed to any formal languages which arecommon in programming this is a pleasant task, for users lacking this expertise this is anear impossible task.

The alienation of such users by its design does not harm LaTex, it was not specifi-cally designed for them. What this alienation does is avoid solving the issues of Section1.1.1. Primarily due to this the proposed tool will provide greater value for such userby abstracting away the need of understanding such syntax. Providing an environmentwhere the content of the document is the main focus.

1If not a bit cluttered.

9

1.4 ConclusionIn this chapter the issues of the cost incurred due to non-machine readable files requiringtypesetting by humans was introduced. The ramifications of such costs are concerning,reducing the accessibility of papers in academia does not aid with furthering research. Atool which solves such issues was proposed. Noting its scope produced an outline of theprojects tasks. The inclusion of functionality which simplifies the citation of externaldocuments is required in order to improve the adoption of the tool. The suggestedtool differs from other WYSIWYG tools by supporting machine readable files, whilstmaintaining the same user interface conventions.

10

Chapter 2

Development

After reading this chapter the steps taken during development of the project should beunderstood. Following the conventional development cycle, this chapter covers eachstage in turn. The research and requirements performed during the project is discussedinitially, followed by the project’s design. The final step discusses the implementationof the system, with evaluation being covered in the next chapter.

2.1 Research and Requirements GatheringResearch for this project was fairly vast, due to a large amount of new topics that re-quired additional learning. Among these the most notable was the programming lan-guage in which the project is built in and the frameworks available for the selectedlanguage. The need to identify key aspects of papers is required in order to target therelevant functionality for the user. In order to further the knowledge in this area thepaper by Constantin et al. [5] regarding a document component ontology was read.Ultimately the level of this research was overly ambitious for this project, settling ondirectly supporting the JATS XML format.

2.1.1 Programming LanguageThe largest difficulty in the decision of which programming language to build the projectin was the large number of available languages, many of which have various positivesfor differing tasks. The solution was to select a language of which the programmerhas experience with, alleviating the requirements of learning a new language. Thisoption was not adopted during this project, due to the amount of experience availableby learning a new language.

With the simple option eliminated, primarily Java, the next step was to identify whatlanguages provide great functionality for building the proposed tool. This included

11

the availability of well established graphical user interface(GUI) frameworks and crossplatform support. This whittled the selections down to C++ and JavaScript.

JavaScript has the benefit of being run through the users web browser, easily sup-porting cross platform applications. With a large amount of functionality for buildinga GUI application this certainly offered the platform required for the project. The al-ternative programming language is C++, which is widely used in industry, with manylibraries and frameworks supporting building of cross platform GUI applications. Ulti-mately the decision boiled down to three points: which could be learnt the fastest, whichwas similar enough to languages already known and which had the largest benefit forpossible future project. Considering these three points the conclusion to decide C++ asthe primary programming language was taken. The belief that adopting such a languagedue to the similarities with Java and C1 would be relatively painless. With the possibil-ity of being useful in future projects during or after university due to the popularity ofthe language, learning C++ would be very beneficial at this stage of study.

2.1.2 FrameworkThe logical step after choosing the programming language is to identify the frameworksand libraries required to aid with developing the project. For this project the require-ments to be cross platform and have GUI design support are necessary. A possibleframework for achieving this is wxWidgets[24]. Supporting cross-platform support forbuilding a GUI application this is ideal. Another framework that fits these requirementsis Qt[21]. With it’s recent release of Qt5.52 it has a myriad of support for building sucha tool. Providing cross platform functionality in a seamless manner for the developerand various ways of designing the GUI environment that is well documented. The classhierarchy of this framework is very similar to Java’s Object hierarchy, providing a sim-ilar design environment as utilised previously during the degree. An extensive amountof documentation is available on all classes online, greatly aiding with the adoption ofthe framework. Due to these points and the access to knowledge available through mysupervisor, it was decided that Qt would be the framework utilised during this project.

The most interesting feature provided by Qt is the signals and slots mechanism. Thisis a reliable way for classes to interact with one another in an event driven manner. Thisfeature is utilised in order to provide the Qt test suite. Allowing for easy separation ofproduction and test code, with the capability of building data-driven tests. Improvingthe readability of these tests greatly.

1Both taught through University courses2Released on the 1st of July, 2015

12

2.1.3 Requirements GatheringThe approach to requirements gathering adopted during this project followed a moreAgile approach than introduced during the degree. This methodology for acquiring theneeds of the project appealed due to the large amount of adoption in industry as well asthe enrolment in an Agile course during the first semester of third year. The learningof such approaches as user stories, task boards and reflection aided greatly during theproject, with further improvements to various areas of study.

User stories are a collection of short sentences regarding tasks the system shouldperform. Highlighting the value for the user in question. Upon practice of such anapproach the capability to describe a thin end to end slice of functionality in these storiesbecame a useful skill, aiding with scheduling tasks for an iteration.

Task boards further aided the benefits from user stories, having a visible represen-tation of what was currently in progress and what was completed, aiding with timemanagement. The number of stories to be undertaken during an iteration was madesimpler by the action of moving around and ranking the stories.

Other approaches to requirements gathering would have required less learning andtherefore been more efficient. Despite this, the opportunity to have a taste of the Agileapproach to software development was invaluable, allowing personal analysis of theeffectiveness of such an approach to be undertaken.

A large issue with the requirements gathering was the lack of prospective users todiscuss the tool with. Ideally the interaction with users in subject areas outside of Com-puter Science, Maths and Physics would have been on hand during the requirementsgathering phase of the project. Despite the inability to achieve this communication, theprocess of designing such requirements as a developer introduced an understanding ofthe issues surrounding requirements gathering.

2.2 DesignDesign of the project will be described with the aid of numerous diagrams. The overallsystem architecture is initially covered, highlighting important sub-systems. These sub-systems deal with the required file format, the citation functionality and the documentrepresentation.

2.2.1 System ArchitecturePrimarily the design of the system architecture revolved around attempting to simplifythe user interaction, utilising pre-existing Qt5 graphical interface classes. Figure 2.1illustrates the overall system, with major subsystems and their communications noted.

13

]Qt5

]Citation

]Document

Representation

]File

Read/Writer

Citation request

New reference

User input

GUI update

XML filewrite

XML fileread

Document alteration

Update GUI

Read JATS XMLfile

Write JATS XMLfile

Figure 2.1: System architecture diagram for the tool.

The user interaction is primarily handled with Qt5 classes, such as QButton(for buttons)and the QTextEdit(for user interaction with the document).

In order to follow the Model-View-Controller(MVC)[13] methodology, the internaldocument representation is separated into a sub-system of its own.

Interfacing between the internal document representation and the JATS XML file hasbeen separated into its own subsystem to abstract the constraints of a document to be anXML file. This utilises QT5’s XML classes, allowing for a large number of complexityto be abstracted away.

The final major sub-system in the diagram deals with the citation requests. Theseparation of this module from the others reflects the low-coupling between the taskof searching for a citation and the upkeep of a document. Simplifying the interfacebetween these tasks and the maintenance of the internal document.

2.2.2 Machine Readable File FormatArguably the most important sub-system with regards to the value added to the user isthe file read/writer. This is illustrated in figure 2.2. The importance of this is in allowinga general document built with the tool to be able to interface with the targeted machinereadable file format.

In order to simplify the interaction between other systems, the interface for thissubsystem was very basic, allowing only reading and writing of files along with errorhandling. With the aid of QT5’s XML file handlers, the task of utilising XML files wassimplified. The only real issue is translating the document representation into an XMLfile. This is accomplished through two adapter modules, one for reading and the other

14

Document Reader/WriterInterface

Write toJATS XML File

Read fromJATS XML File

JATS XMLFile

Document Document JATS XMLFile

ConfirmationRead/Write

Request

Figure 2.2: Architecture diagram for reading and writing a document from/to a JATSXML file.

for writing. This allows separation of both tasks whilst having the same basic interfacefor other systems.

2.2.3 Semi-Automated Citation

CitationInterface

CrossRefManager

NewReference

CitationRequest

QueryCrossRef API

Result of Query

Figure 2.3: Architecture diagram for citation sub-system.

The citation module in figure 2.3 contains a separate GUI from the other sub-systems. This allows the acquisition of information for searching a citation to be per-formed without altering other sub-systems.

The interface is very basic, initially propagating the GUI when called and returninga new reference class once complete. Once the GUI has received the request for a newcitation a query to the CrossRef API is performed by a manager class. This responsepopulates a number of references which are displayed to the user. Once a reference isselected for inclusion it is returned to the relevant class.

15

Document

Front Body Back

... ...Paragraph

...

Section

...

Figure 2.4: Partial layout of internal document representation.

2.2.4 Document RepresentationIn the process of designing the internal document representation many formats wereconsidered. Ultimately the logical approach was to reflect the JATS XML structureinternally, aiding with the translation from file to document.

The JATS XML file structure is very extensive. Figure 2.4 illustrates a partial amountof this, displaying the top layer of a document structure in JATS XML. The front con-tains title and author information as well as other common data described before themain body of a document. The back contains the bibliography and appendices. The realmeat of the document lies within the body, for simplification figure 2.4 only containsa single level in the body. As expected the body may contain sections and paragraphs,which in turn contain further data such as text and images.

This document structure can efficiently be reflected through the class hierarchy ofC++ and QT5. Aiding with the translation of XML files to the document, but allowingfuture translations of other formats to be possible by producing a new adaptor.

2.3 ImplementationUpon completing the design of the system, implementation was reduced in complexity.A large amount of similarity can be seen between the implementation diagrams and thedesign diagrams, due to the usefulness of the design steps. The major alterations weredue to the requirements with user interaction, being dealt with through QT classes.Integration was a step not covered in depth during the design step but was a key part ofthe project. A large number of issues were uncovered during this step, highlighting the

16

need to allow plenty of time for the integration of a system. For various screenshots ofthe final tool refer to appendix A.

2.3.1 Machine Readable File Format

Figure 2.5: UML diagram for file interaction sub-system.

The implementation of the file reader and writer was made very simple with theaid of QT’s QXmlStreamReader and QXmlStreamWriter classes. These classes had anumber of helpful methods in producing and reading a file in the XML format, of whichcould easily be valid JATS XML by the definition of relevant tag names.

Figure 2.5 is a loose UML diagram3 showing the file structure of the sub-system, afew helper methods are omitted for readability. The figure highlights the simplicity ofthe adapter classes, with separate classes for the reading and writing of files the logic isnicely separated.

Largely this sub-system required no deviation from the design in subsection 2.2.2.The largest benefit to this implementation is the simplicity of extending the supportedtags, this being achieved by implementing a new helper method and inserting logic toidentify where the new tags are utilised.

Downfalls of this implementation included the size of the classes. With such a largenumber of separate tags appearing in the JATS XML standard the file grew to an unrulysize quickly.

3Loose with regards to the rigidity of the structure and the adherence to UML standards.

17

2.3.2 Semi-Automated Citation

Figure 2.6: UML diagram for Citation sub-system.

Another successful implementation following the design was the citation sub-system.With a number of classes provided by Qt, the communication between the CrossRefserver and this system was simple to implement. The QNetworkAccessManager classabstracted away much of the complexity of such requests, allowing for robust and read-able code.

Most of what is not described in figure 2.6 are the GUI decisions where results aredisplayed to the user, selecting one(or no) relevant references which is then returned tothe caller of the module.

Positives of this implementation is the large amount of separation from other mod-ules. Allowing development and testing to be undertaken regardless of the progress ofother sub-systems.

A small number of aspects required diverging from the design of this module. Pri-marily the extent of the GUI functionality. This altered due to the requirement of simpleuser interaction, which was not fully considered during the design.

The major downfall of this sub-system is the density of some code. Being an earlymodule to be completed the code quality was lacking comparative to other sub-systems.This lead to more difficulty during testing.

2.3.3 Document Representation

A simple comparison of the design in figure 2.4 and implementation in figure 2.7highlights how closely the implementation of the document sub-system and the designis. Following this the implementation directly reflects the structure outlined by JATS.

18

Figure 2.7: Partial UML diagram for the document representation sub-system.

This is in order to allow simple translation from a class hierarchy into the targetedmachine readable format.

Utilisation of Qt’s signal and slots mechanism in transferring information down thedata structure allowed for simple alteration of sub-classes in an intuitive manner. Anexample of this is the insertion of a citation. Once a citation has been constructed itrequires insertion at the relevant position, or discarded if no valid position is identified.This utilises the QTextCursor class as positioning in the document, which is tied to theunderlying interface with the QTextEdit class. Simply tying the relevant parent signalsand child slots on construction of a child allows propagation of the signal to the childnodes without stalling the GUI noticeably.

The benefits of this implementation is the simplicity of converting the document toa JATS XML compliant file. Simply traversing the hierarchy in a depth first manner,writing the relevant information as we progress produces the required structure.

Alterations from the design included supporting higher positioning information in adocument aiding the GUI appearance, requesting information from the user in variousways. This lead to the implementation of a second adaptor class interfacing between adocument and the QTextEdit class, this being the TextFrame class. This class encom-passes a collection of paragraphs and treats them as frames, allowing maintenance ofoverall positioning in the document to be simplified.

Issues in this implementation included the ties with the QTextEdit class, whichcaused a number of errors with user interaction. Despite the clear gains from the signalsand slots mechanism offered by Qt, the utilisation of this complicated the testing anddebugging of the code.

19

2.3.4 IntegrationThe most difficult aspect of the project was the integration of the aforementioned sub-systems. Despite the best of intentions in simplifying the task of integration for eachmodule, the actual implementation of this was far from ideal. The principle that brokedown causing such difficulty was the understanding of the user interaction with theQTextEdit class and its interface class QTextCursor. Largely the difficulty with thiscommunication was the inconsistency with the positioning of the virtual cursors for theuser and the internal document. This lead to the omission of user text in the documentand various layout discrepancies. These required further redesign to resolve, which dueto the time constraints was impractical.

The solution for these issues was not an elegant or simple one, due to the failure inallocate adequate time for integration. The solution adopted was to have logic whichverified the consistency of the document and QTextEdit every time a request to read thedocument is received. This clearly was lacking due to the difficulty with adding newsub-classes to the document efficiently and the introduction of difficult to identify bugs.

2.4 ConclusionIn this chapter the development of the tool for the project was covered. The research ledto using C++ as the programming language and QT as a framework. This frameworkprovides cross-platform support and a number of features desirable in such a project.In performing requirements gathering many new approaches were taken, such as UserStories. These proved useful and aided with the pacing of the project.

The parallels between the design and implementation of the project were made ev-ident with the design diagrams and the UML diagrams of the implementation. Duringthe integration stage of the project a number of issues were uncovered, with little timeto solve these issues an important lesson was learnt. This lesson was of the amount ofinexperience I have with such a large project and the problems this caused.

20

Chapter 3

Evaluation

In this chapter the approaches undertaken in order to evaluate the produced tool willbe described. The difficulty with the evaluation was due to the extent of the projectand lack of prior experience. A number of steps were taken to insure the quality of thefinal product, many of which were successful. The most versatile of these that provedvery useful was regular reflective sessions. In order to achieve a degree of belief in thecorrectness of the project a number of tests were performed. Followed by validationof the produced JATS XML file in order to ensure its correctness and the number ofsupported tags.

3.1 QualityIn order to gauge the quality of a piece of software there are a large number of met-rics available. Due to the sheer number of these, paired with the ease of getting lost inthem, the focus for quality was primarily shifted into adopting various processes whichaid with maintaining quality. Among these the most effective were reflection, refactor-ing, test first development, user stories and task boards. The adoption of various Agilemethods were undertaken throughout the project in order to widen understanding.

3.1.1 Refactoring and ReflectionRefactoring is the process where analysis of written code is performed in order to iden-tify various optimisations or abstractions that can improve the code quality and re-usability. Experienced application of this process aids with identifying future problemsand improve on the interface of a class or sub-system.

Reflection is a process which complements refactoring well. This is an approachwhere a developer considers the previous week’s or iteration’s work. Identifying whatwent well and what did not. The aim for this process is to improve the development of

21

future code by learning from past mistakes. Admittedly this is a difficult task to achieve,but once the process is fully understood the benefits are immeasurable.

These approaches work spectacularly well together, requiring minimum effort oncethe initial understanding is acquired. This in itself is an invaluable skill for future en-deavours, which aided greatly throughout this project.

The best example of these processes being used, providing a beneficial result is dur-ing the integration stage. One week into the iteration and the progress was far lower thanexpected, with a number of issues becoming apparent. The reflection session for thisweek aided with identifying issues with the interaction between the internal documentand the QTextEdit class. This allowed for designing helpful integration tests, whichfurther aided with overcoming the issues by the refactoring of code.

3.1.2 Test First DevelopmentTest first development(TFD) is a simplified version of test driven development(TDD)[2].The reason as to why the simplified version was used was due to the inexperience withsuch an approach and the large number of other unfamiliar processes utilised during theproject.

The first step of test first development is to design the unit tests for a piece of func-tionality, adopting a programming with wishful thinking approach to the naming andexistence of classes. Next the production code is developed, which is targeted at pass-ing the unit tests and little else.

The benefit of this approach to developing classes is the speed of which code canbe produced, no need for spending time on lengthy design approaches. This is also anatural way of approaching many programming issues, learning more about the problemas the development process progresses.

During the project, this methodology was utilised in the design of many documentrepresentation classes. Describing the expected behaviour of the classes prior to produc-ing the code was simple with Qt5’s test library. This produced very high quality classeson the whole, with few issues where inexperience was at fault, such as the connectionwith QTextEdit.

3.1.3 User Stories and TaskboardsContinuing with the theme of applying Agile approaches during the project, the UserStory[4] and Taskboards practices were adopted. User stories were applied as a part ofthe coursework for the COMP33711 Agile course during first semester.

The selection of user stories over the other choices of practices was due to the pos-sible gains from the process. This being a more intuitive approach of acquiring require-ments for the required software, avoiding the lose of time due to unnecessary function-ality and gathering pages of requirements. The process involves constructing so called

22

user stories by the customer. These are short notes specifying what they wish the systemto achieve, the context of which the story is required and the value it would bring theuser. This is a fast way of attaining the requirements from a customer and allows variousother approaches to be adopted in tandem increasing the benefits.

Taskboards or big visible charts is an Agile approach that attempts to display theprogress of a project visibly, so all team members have easy access to it at all times.Appendix D contains a small number of user stories and their usage with taskboards.The use of this in such a project with only one developer was in having a taskboard ofall current and completed functionality visible at all times. This was simple when pairedwith user stories. The benefits are the capability of gauging the progress and adjustingthe speed of work as necessary.

The quality gained by both approaches in tandem derives from a greater under-standing of the projects current state at all times during development. Allowing smallalterations as necessary to maintain progress and avoid common pitfalls such as feature-creep as early in the development process as possible.

Achieving the use of these processes in the project was very simple. Acquiringa number of sticky notes for the user stories, later small pieces of card, allowed thetaskboard to be a wall in a room. During the first few iterations these processes aidedwith identifying the initially required tasks to complete, focusing on user value. Forsuch an inexperienced developer this was invaluable with focusing efforts in the relevantareas early in the project.

3.2 CorrectnessCorrectness of a piece software is difficult to fully achieve, but is required in order toevaluate the extent of completion for a system. Sadly the experience as to achieving per-fection in a project is elusive, especially for a student. Attempts to assure the maximumcorrectness during the project included various testing and validation. Unit Testing[22]is the most commonly adopted form of testing during this project, with other forms suchas integration, system and graphical user interface testing utilised in smaller quantities.Validation of the produced XML files was performed with online accessible tools suchas the PMC XML Validator[19].

3.2.1 Unit TestingUnit testing was achieved through Qt5’s testing framework. For all intensive purposesthis can be equated to the JUnit1 testing suite for Java, for further information refer toappendix B.

1Which is assumed that the reader has experience with.

23

This form of testing was adopted continually throughout the project. Primarily per-formed at the end of an iteration, but in the application of test first development this wasdone at the beginning.

Unit testing played a valuable role in obtaining confidence in the correctness ofclasses, especially those of the document representation. The testing of classes suchas Paragraph highlighted initial issues with the interaction with the QTextEdit class.Which in the case of class interaction was resolved, sadly this level of testing did notidentify the issues with user interaction that became an issue later in the project.

3.2.2 Integration TestingIntegration testing[11] identifies issues regarding communication between sub-systems.Reinforcing the belief of correctness for larger section of the system than unit testing.

This form of testing was not as natural to adopt, with no formal explanation of thecommon approaches to building such tests. Despite this aspect their incorporation didprove very beneficial, identifying larger issues throughout the system with regards tothe user interaction.

These tests were constructed during the final stages of the project, in the iteration setaside for integration. As mentioned this achieved invaluable results in identifying faultsin the system, the drawback for this was the lack in time to resolve the issues identified.

3.2.3 System TestingSystem testing[3] is fairly similar to integration testing. The deviation is with the tar-geted system; integration testing targets sub-systems whereas system testing targets theentire system.

This form of testing was primarily omitted during the project due to timing con-straints and the issues uncovered during integration testing. Lacking in such tests leftthe final product’s correctness in question. Although far from ideal, this has been abeneficial experience in highlighting the need for many forms of testing in any project.

3.2.4 Graphical User Interface TestingThe final form of testing researched for use during the project is GUI(Graphical UserInterface) testing[15]. This is the process in which the graphical user interface is tested,such as button presses responding in the correct manner. This is a fairly peculiar formof testing, vaguely identifying the causes of errors. The GUI is only finalised duringthe last iterations of the project due to the abstraction from the internal systems logic.The underlying issues with the system may not be identifiable from GUI tests failing,reducing the benefit for a developer.

24

Due to time constraints and the small gain from this form of testing it was notadopted during this project. Despite this the research into how this could be achievedwas performed, which identified Qt5’s support for such testing[20].

3.2.5 XML ValidationMoving away from testing we have a key aspect for validating the correctness of thetool. Validation of the files produced by the tool required rigorous application to ensurethe targeted file format was indeed supported. This was achieved with multiple toolsavailable online[19, 18] which were recommended by the JATS XML website[10].

In order to support valid files the supported XML tags were designed incremen-tally into the system. Supporting the bare minimum of a valid JATS XML file initially,building further support as the tool progressed. The identification of invalid tags orunexpected text this way allowed adjustments to be adopted rapidly.

3.3 ConclusionThis chapter consisted of evaluating the quality and correctness of the produced tool.In order to maintain the quality various steps were taken. Most effective were the com-bination of regular reflective sessions and refactoring. The correctness of the tool wasascertained by a number of tests. Unfortunately the time constraints reduced the cover-age of these tests to an undesirable degree. The validity of the produced JATS XML filewas ensured with the use of validators found through the JATS XML website.

25

Chapter 4

Reflection and Conclusion

Prior to discussing the conclusion of this report a reflection on the project is performed.This is a more personal analysis of how I felt the project has gone. The goal of this isto allow the analysis of how much was learnt during the course of this project, in orderto aid me with future projects by suggesting a number of steps to undertake which willimprove myself.

4.1 ReflectionAs mentioned previously, reflective sessions have been very successful during the project.The planning and management of the project is covered in order to identify issues withtiming and how the project was approached. Through analysing the positives and nega-tives of the project a greater understanding of how I have changed throughout the projectis attained. Finally noting some suggestions to follow for future improvements allowsthe continued furthering of my capabilities.

4.1.1 PlanningThe initial plan covered only the vague outlines for each iteration. This suggested havingthree week iterations, accounted for other coursework and provided milestones. Theseaspects of the project were largely met, other than the integration stage of development.Sadly this plan failed to be of much use in the project. Largely this can be contributedto my inexperience with such planning and the amount of knowledge unavailable at thetime of initial planning.

The adoption of Agile planning processes, such as user stories and reflective ses-sions, provided more aid with designing the project and maintaining pace. This couldbe contributed to the capabilities of these approaches in being adjusted continually, al-lowing errors to be easily amended incrementally. During the second iteration these

26

processes truly aided with overcoming issues of progress. The reflective session aidedwith identifying some overly large user stories, which when broken down provided anew understanding of the problems. Achieving this in a short amount of time preventedthe pacing of the project from suffer.

Not all aspects of planning went as desired. During the turmoil of the integrationstep in the project, much of the planning suffered. Many issues were identified andovercome without constructing any formal plan. Code quality clearly suffered duringthis time, which ironically furthered the amount of time required to further adjust thesystem.

Planning has had a strange relationship with the project. Providing a number of ben-efits but ultimately falling to the side as more important and stressful tasks arose. Thiswas a clear mistake, which should be avoided in future. To aid with further capabilitieswith planning the task of regular reflective sessions is advised. Further to this practicewith large projects will be very beneficial, especially when working in a group.

4.1.2 ManagementThrough this project my management skills were tested to a higher level then throughoutany other course during my degree, due to the scale of the project. This aspect uncoveredissues with personal management and dealing with large work loads.

Noting the number of hours worked during each week was very beneficial, aidingwith achieving the targeted number of hours for working on the project. This allowedtime to relax during some weeks due to good progress and further work in times of need.Allowing work to be completed in other courses, alleviating some stress. The negativeof noting the hours was the sudden realisation of how much time had been spent in frontof a computer monitor. Not having a profound effect on the project as a whole, this wasfairly demoralising.

User stories aided with the management of the project as a whole. Allowing theunderstanding of the project’s current progress and the next required task aided withtime allocation. Further benefiting by the maintenance of the amount of scope currentlyconsidered, preventing feature creep.

Management of the project broke down during the final weeks of development. Dur-ing the integration stages many of the tasks undertaken to aid with management weredisregarded in the hopes to increase the speed of progress. This was a fairly inadvis-able course of action, only benefiting the understanding of why such actions should beavoided.

4.1.3 Analysis of Positives and NegativesAmong the positive aspects of the process undertaken during the project, the most note-worthy are the Agile processes and testing. These are areas of which prior to under-

27

taking the project little knowledge was known. During their application many of theirbenefits and requirements were highlighted, providing insight into why they are benefi-cial and when they are not. The research stage of the project also went well. Coveringmany topics, highlighting my capability in acquiring new knowledge effectively.

Not everything went well during the development of the project, but these expe-riences were more valuable with regards to my learning and self improvement. Theintegration stage of the project brought attention to the difficulty of such a task, sug-gesting more time was required than outlined in the initial plan. The other negativeshighlighted during the project was my lack of skills with the dissemination of infor-mation effectively. This can be contributed to two factors: the lack of experience andnervousness. The improvement of such aspects will not be simple, but are integral tofurthering my capabilities in future.

4.1.4 Identification of Knowledge GainedA number of technical aspects were covered during the project. Largest among thesewas the programming language C++. Further to this the understanding of frameworkssuch as Qt was reinforced.

The experience of testing showed many aspects of building a project. Furthering myknowledge with the standard a project must achieve and various issues with attainingit. The balance between tests that cover all aspects of a project and tests that run inminimal amount of time was a new dynamic which displays further issues for largeprojects unknown to me.

Invaluable to my future are the weaknesses highlighted in section 4.1.3. So long asappropriate steps are taken, these flaws will surely be overcome with time.

The final bit of knowledge attained during the project worth noting is the benefits ofregular reflective sessions. Aiding with identification of numerous issues this processwill need further application in the future.

4.1.5 Future ConsiderationsAdvice for the future is a key part of self improvement. The need to improve greatly incommunication and dissemination of information is highly advised. The beneficial ef-fects of the application of Agile processes was evident. Further use of such approachesshould be undertaken, optimally within teams in order to formulate a greater under-standing of these practices.

Further experience with large project is advisable. The chance to gain this experi-ence through industry is highly beneficial and should be sought after in order to covermany aspects avoided during this project.

A final note is to maintain the use of reflective session. Furthering this throughnoting topics of importance at each session, allowing further considerations to be taken

28

over a larger amount of time.

4.2 ConclusionThe overall goal of the project was to produce a word processing tool for the composi-tion of scholarly documents. The tool produced achieved in providing the requirementof supporting the JATS XML file format. This format was targeted in order to alleviatethe costs incurred during the typesetting phase of publishing a manuscript. The citationinterface provided the functionality to draw in new users. The use of CrossRef in ac-quiring the data on external documents lead to a powerful feature. Testing was adoptedcontinually throughout development in order to maintain the quality and correctness ofthe tool. Issues with the integration stages due to time constraints and the interactionthrough the QTextEdit class were the largest negatives of the project. Requiring furtherexperience in order to avoid such issues in the future.

Future possibilities for the project are to improve on the graphical user interface,providing a more distraction free environment to add further value to the user. Imple-menting support for features which were excluded during the project, such as equationsand figures. These are of great value for the user but require a well tested base tool tobe achieved prior to their adoption. The final addition to the tool could be the inclusionof collaborative document composition features, this being a popular functionality inrecent word processors.

29

Bibliography

[1] About DataCite. 2016. URL: https://www.datacite.org/about-datacitehttps://www.datacite.org/about-datacite (visited on 04/28/2016).

[2] Dave Astels. Test Driven Development: A Practical Guide. Prentice Hall Profes-sional Technical Reference, 2003. ISBN: 0131016490.

[3] Boris Beizer. Software System Testing and Quality Assurance. New York, NY,USA: Van Nostrand Reinhold Co., 1984. ISBN: 0-442-21306-9.

[4] M. Cohn. User Stories Applied: For Agile Software Development. Addison-Wesleysignature series. Addison-Wesley, 2004. ISBN: 9780321205681.

[5] Alexandru Constantin et al. “The Document Components Ontology (DoCO)”. In:(Sept. 18, 2014). URL: http://www.semantic-web-journal.net/content/document-components-ontology-doco (visited on 04/28/2016).

[6] CrossRef. 2016. URL: http://search.crossref.org/ (visited on 04/28/2016).

[7] Elsevier OA Price List. [Online]. 2016. URL: http://cdn.elsevier.com/promis_misc/j.custom97.pdf (visited on 05/03/2016).

[8] Chen Guttman. Open Access vs. Subscription-Based Scientific Publications. [On-line]. 2013. URL: http : / / blog . labguru . com / blog - labguru / open -access-vs-subscription-based-scientific-publications (visited on05/03/2016).

[9] How much does typesetting cost? [Online]. 2015. URL: https://svpow.com/2015/06/11/how-much-does-typesetting-cost/ (visited on 05/03/2016).

[10] JATS Wiki - Tools. 2016. URL: http://jatswiki.org/wiki/Tools (visited on04/28/2016).

[11] Paul C. Jorgensen and Carl Erickson. “Object-oriented Integration Testing”. In:Commun. ACM 37.9 (Sept. 1994), pp. 30–38. ISSN: 0001-0782. DOI: 10.1145/182987.182989. URL: http://doi.acm.org/10.1145/182987.182989.

[12] Journal Article Tag Suite (JATS) Wiki. 2016. URL: http://jatswiki.org/wiki/Main_Page (visited on 04/28/2016).

30

[13] Glenn E Krasner, Stephen T Pope, et al. “A description of the model-view-controller user interface paradigm in the smalltalk-80 system”. In: Journal ofobject oriented programming 1.3 (1988), pp. 26–49.

[14] Markdown. 2016. URL: https://daringfireball.net/projects/markdown/(visited on 04/28/2016).

[15] Atif M Memon. “GUI testing: Pitfalls and process”. In: Computer 8 (2002),pp. 87–88.

[16] Pandoc - About Pandoc. 2016. URL: http://pandoc.org/ (visited on 04/28/2016).

[17] Steve Pettifer. Project Proposal. 2016. URL: http://studentnet.cs.manchester.ac.uk/ugt/year3/project/projectbookdetails.php?projectid=26471(visited on 04/27/2016).

[18] PMC Style Checker. 2016. URL: http://www.ncbi.nlm.nih.gov/pmc/tools/stylechecker/ (visited on 04/28/2016).

[19] PMC XML Validator. 2016. URL: http://www.ncbi.nlm.nih.gov/pmc/tools/xmlchecker/ (visited on 04/28/2016).

[20] Qt Documentation: Simulating GUI Events. 2016. URL: http://doc.qt.io/qt-5/qttestlib-tutorial3-example.html (visited on 05/02/2016).

[21] Qt programming framework. 2016. URL: http : / / www . qt . io/ (visited on04/28/2016).

[22] P. Runeson. “A Survey of Unit Testing Practices”. In: IEEE Software 23 (4 2006),pp. 22–29. ISSN: 0740-7459. DOI: 10.1109/MS.2006.91.

[23] Jeffrey J. Sallaz. Your Paper Has Just Been Outsourced. [Online]. 2016. URL:http : / / isa - global - dialogue . net / your - paper - has - just - been -outsourced/ (visited on 05/03/2016).

[24] wxWidgets: About. [Online]. 2016. URL: http : / / wxwidgets . org / about/(visited on 05/03/2016).

31

Appendix A

Screenshots of Text Editing Tool

The following screenshots show the final text editing tool. Figure A.1 displays a smallJATS XML file ready for editing in the tool. In figure A.2 the tool is suggesting multiplepapers that match a requested search string for citation. The final figures A.3 shows anoutput JATS XML file that has been translated into LaTex and then processed. Thisshows the extent of which supporting a machine readable file format offers, allowingfor automated translation from one file format to the other.

Figure A.1: Screenshot of the tool with an example JATS XML file open.

32

Figure A.2: Screenshot of the tool acquiring an external reference.

33

Figure A.3: Resulting LaTex files after conversion from JATS XML.

34

Appendix B

QT5’s Testing Framework

Qt5’s test framework is a wonderfully integrated system, made all the easier by theuse of QT’s Creator IDE. Figure B.1 shows a small example of what the supportedQTest framework requires to run automated tests. The Q SLOTS declaration utilisesQt’s powerful signals and slots mechanism to allow external classes to identify and callthe test methods. This is all provided through Qt’s meta class system which is similarto Java’s class system.

Figure B.1: Example test file utilising Qt’s QTest framework.

35

Appendix C

JATS XML Example File

The following three images are screenshots of a small JATS XML. This illustrates thelogical outlay of the XML tags defined by the JATS standard. The shown examplefile was commonly utilised throughout the project, being translated into the LaTex filesshown in figure A.3.

Figure C.1: Example of JATS XML file: Top

36

Figure C.2: Example of JATS XML file: Middle

Figure C.3: Example of JATS XML file: Bottom

37

Appendix D

User Stories and Task-Board Images

Following are a small number of user stories constructed during the project. Despite thelow quality images, these illustrate the form of requirements gathering performed andthe way they were utilised with taskboards. Figure D.4 shows the taskboard which is awall in the room where development was undertaken, allowing for a visible display ofthe current projects progress.

Figure D.1 reads: As a publishing body, I want to receive files in the JATS XMLformat; so that I may store and process these files without altering pre-existing process-es/tech.

Figure D.2 reads: As an academic, I want my document to be divided into sectionsand subsections; so that I may construct a nicely formatted paper.

Figure D.3 reads: As an academic, I want the tool to automate the act of citing apaper; so that I may spend less time looking online for citations and more time typing.

38

Figure D.1: User Story example 1.

Figure D.2: User Story example 2.

39

Figure D.3: User Story example 3.

40

Figure D.4: Example of user stories utilised with taskboards.

41