Press
A Third Year Project
Thomas Walters
Computer Science B.Sc.
April 2015
Supervised by Dr John Latham
School of Computer Science, University of Manchester
Abstract
Publishing education materials is an inefficient and slow process, currently large groups of writers, designers and publishers must work in concert
to create even the most rudimentary of resources. This report is an examination of the idea that this process can be greatly simplified and benefit from
automation in certain areas, while still producing high-quality artefacts for
use in the classroom environment.
The report will outline the design, implementation, and evaluation of a
system designed to replace the disparate software tools used for creating and
publishing educational materials. It begins with an exploration of the current
landscape and the problems encountered by those within it, before formulating the goals that would lead to the ideal tool for resource production. After
this the design and development of the project is described in detail, with the
challenges, trade-offs, and outcomes enumerated in full.
Finally this report will investigate the results of the process, and evaluate
the project with respect to real-world users.
i
Acknowledgements
I would like to thank my supervisor Dr. John Latham for his critical
eye and insightful discussions throughout the project. Furthermore I would
like to thank Emma Bradbury and my group of evaluation users who helped
shape my project into a product with real-world applications for education
and beyond. Finally I’d like to thank my family for their continuing support
as always.
ii
Contents
1
2
Introduction & Context
1.1 Introduction . . . . . . .
1.2 The Problem . . . . . . .
1.3 Existing Solutions . . . .
1.3.1 Microsoft Office
1.3.2 LATEX . . . . . .
1.3.3 Other Tools . . .
1.4 The Goals . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Development
2.1 Initial Design . . . . . . . . . . . . . .
2.2 Software Engineering Approach . . . .
2.3 Selecting The Right Tools . . . . . . . .
2.3.1 Architecture . . . . . . . . . . .
2.3.2 Languages . . . . . . . . . . .
2.3.3 Web-server Frameworks . . . .
2.4 System Components . . . . . . . . . .
2.4.1 Server-side Code Structure . . .
2.4.2 Client-side Code Structure . . .
2.5 Editor . . . . . . . . . . . . . . . . . .
2.5.1 The Ideal Output . . . . . . . .
2.5.2 WYSIWYG Editing . . . . . .
2.5.3 Word-processing Technologies .
2.5.4 Learning to Type . . . . . . . .
2.5.5 Uploading & Managing Images
2.5.6 Review Mode . . . . . . . . . .
2.6 Online Views . . . . . . . . . . . . . .
2.6.1 Textbooks . . . . . . . . . . . .
2.6.2 Slide-shows . . . . . . . . . . .
2.6.3 Handouts . . . . . . . . . . . .
2.7 Off-line Views . . . . . . . . . . . . . .
2.8 Slide-show Editor . . . . . . . . . . . .
2.9 Slide-show Controller . . . . . . . . . .
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
2
2
3
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
6
9
9
10
10
13
15
15
16
17
18
20
22
23
23
23
25
26
27
29
3
Testing
3.1 Unit Testing . .
3.1.1 Client .
3.1.2 Server .
3.2 System Testing
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
32
32
33
4
Evaluation
35
5
Conclusion
37
Appendices
39
A Taskboard Notes
A.1 Week 1 - October 26th .
A.2 Week 2 - November 3rd .
A.3 Week 3 - November 10th
A.4 Week 4 - November 17th
A.5 Week 5 - November 24th
A.6 Week 6 - December 1st .
A.7 Week 7 - December 8th .
39
39
39
40
40
40
40
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B UI Survey
41
C Final Evaluation-user Survey
42
iv
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
My task-board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Browser Market Share Jan-Feb 2015 (rounded) [2] . . . . . . . . 8
System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
Initial Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Document Sub-object Architecture . . . . . . . . . . . . . . . . . 13
Browser event flow-chart . . . . . . . . . . . . . . . . . . . . . . 14
Comparison of un-semantic and semantic HTML . . . . . . . . . 16
The editor’s formatting buttons . . . . . . . . . . . . . . . . . . . 17
The inline media manager . . . . . . . . . . . . . . . . . . . . . 21
A document in review mode . . . . . . . . . . . . . . . . . . . . 22
An invitation to review . . . . . . . . . . . . . . . . . . . . . . . 23
Comparison of document HTML (left) and converted slide-show
HTML (right) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The slides compared to the handout . . . . . . . . . . . . . . . . 26
JSON for storing slide-show changes . . . . . . . . . . . . . . . 29
Revised System Architecture . . . . . . . . . . . . . . . . . . . . 30
Editor page time allocation . . . . . . . . . . . . . . . . . . . . . 33
BBC News home-page time allocation . . . . . . . . . . . . . . . 33
Above: BBC News home-page rendering break-down. Below:
Press editor rendering-breakdown. . . . . . . . . . . . . . . . . . 34
Active session cohort analysis with the introduction of Press-generated
resources highlighted . . . . . . . . . . . . . . . . . . . . . . . . 35
v
1
Introduction & Context
This chapter introduces the project and describes the contexts and challenges
posed by the problems the work is seeking to solve.
1.1
Introduction
In the educational publishing world materials undergo an arduous and inefficient
process in order to reach the classroom. Writers, proof-readers, editors, designers
and printers must be coordinated in order to create high-quality teaching aids.
When either the content or (as it more often the case) curriculum changes, the
entire process has to repeat itself.
As the co-founder of Rocket Education - a business which produces materials
for colleges in the UK, I had first-hand experience of managing a large base of
content in varying mediums. The company produces online and off-line workbooks and slide-shows among other formats, each of which must be kept-up-to
date and reviewed at least once a year.
The challenges faced at the company led to the inspiration for this project:
could a tool capable of generating all these mediums in high-quality, from one
canonical source of data be created?
1.2
The Problem
As eluded-to above the current state-of-affairs in the education publishing world
is one of inefficiency and duplicated-effort. With the proliferation of information
technology over recent years both traditional publishers and individual teachers
alike have moved from producing just textbooks, into creating complex slideshows and various other formats for students.
Alas, while the diversity of mediums has expanded, the methodology that
leads to their creation has remained fixed. While slide-shows allow for the addition of complex animations and interactivity, in order to create them individuals
1
must undergo the laborious copy-and-paste cycle using content from their textbook counterparts. This duplication of effort also harbours a hidden flaw: when
updating the content writers must check each medium by hand, hoping they don’t
overlook changes in any of them.
Finally although many teachers have become adept at managing a wide array
of content, the design of the materials themselves is often sub-par. As an example
it is standard for teachers to simply print a slide-show’s slides when giving a lesson
- not only is this a waste of ink and paper owing to background-colours and widemargins, but it fails to understand the different between a large screen and a small
page. Custom hand-outs following the same content as their corresponding slideshows designed for the printed page are obviously a superior solution.
1.3
1.3.1
Existing Solutions
Microsoft Office
The current standard for the writing world is Microsoft Office. Word is a powerful word-processor with a low bar to entry capable of handling large and complex documents. While Word allows users to get writing straight away, it lacks
complex formatting tools that are essential for producing every format required.
Advanced users may record macros capable of altering a document’s format, but
this is limited to basic operations on the content.
PowerPoint is a robust slide-show composer and is familiar to almost every
teacher. Sophisticated features such as master slides may be utilised to enforce
strict formatting, but in-order to obtain a professional-looking output users must
spend a substantial amount of time learning how to use the software.
1.3.2
LATEX
Within the scientific community LATEX is the standard for publishing documents.
It offers a wide array of powerful and extensible tools which can be customised
by expert users to produce many different mediums with the same content.
2
The primary drawback to using it however is the fact that documents must be
prepared in a mark-up language. Here a user would be trading the extra workload
of maintaining multiple mediums, for the complexity of adopting the mark-up
language.
Although LATEX enjoys success within higher-education academia, outside of
this environment few publishing companies and teachers are exposed to it.
1.3.3
Other Tools
While word-processors such as Microsoft Word are heavily used by the content
writers, once publishing houses are happy with their work it is shipped to designers who use a number of different tools in order to produce the final product.
These may include Adobe’s InDesign for producing high-quality printed mediums
or some similar publishing package. Although this ensures a high-quality of output, later changes to the content are not reflected in any extra artefacts produced
by designers without manual intervention - a process which necessarily increases
costs.
1.4
The Goals
At the outset the following ‘elevator pitch’ was decided upon for the project:
“Press is a tool for managing education materials in one simple-to-use, yet powerful editor. Using one canonical source for content, it can generate slide-shows,
workbooks, and other materials.” The name ‘Press’ originates from the printingpress used in traditional publishing.
The primary goals for this project were as follows:
1. A Beautiful Editor
As the editor will be the most commonly-used tool for most users it should
be a joy to use - distraction-free and stripped of all unnecessary clutter.
2. Hand-made-esque Output
3
The materials produced by Press must look almost hand-made - while publishing companies have the luxury of professional type-setters, the project
should automate the entire process and create output which is of the highestquality.
3. Ease of Use
Users should not have to read a one-hundred page manual before getting
started. The philosophy of the project should stay out of the way.
4. Time Saving
Users should reap time-savings in utilising Press both in the initial creation
of documents, and in the long-term maintenance of them.
Rocket Education was looking to solve problems which it faced for years - if
they could make the production process more efficient they would be more agile in
the future; and if successful this tool would alleviate the same pains that individual
tutors face when writing and maintaining their own resources.
4
2
Development
This chapter will describe the various design choices and alternatives considered,
then delve into the core aspects of the development of the project.
2.1
Initial Design
At the beginning of the project I formulated a set of four distinct feature-sets that
I would have to work on: the editor was a natural starting point as to produce
content it would first need to be written. I decided that the editor needed to be
easy to use - a manual shouldn’t be required for most operations, yet powerful
enough to accommodate documents of a complex nature.
Next, a slide-show viewer would be necessary to take a document’s content
and generate a high-quality slide-show within Press. While creating an editor
specifically for slide-shows would allow for fine-grained customisation of this
automatically-generated format. I was keen to build a separate editor for slideshows as many teachers have a distinct style for presentations, and would no-doubt
feel frustrated if Press didn’t allow for such control.
Furthermore other formats to be produced would be the text-book - mimicking a professionally-designed printed version of the content, and hand-outs which
would offer an optimised set of notes for use with slide-shows.
Finally I decided that outputting to PDF was a necessity - rather than rely on
an unpredictable processing step between the online and off-line formats, creating
PDFs would guarantee consistent and high-quality output.
2.2
Software Engineering Approach
I was keen to use an agile methodology for the development of the project, and
specifically to take advantage of the task-board technique. This mode of working
was first popularised by David J. Anderson in his book Kanban [1] in which he
describes the Japanese system of production management utilised on the Toyota
5
production lines, and applies it to modern software development & management.
The basic idea is to use small sticky-notes on which you write tasks which are
then placed on a large board split into sections representing different areas in the
development life-cycle. My board was split into four columns:
1. Waiting: Waiting to be actively developed
2. In-Progress: In active development
3. Verification: In testing in order to be verified
4. Complete: Finished development (cleared once a day)
I further sub-divided the board into three rows loosely based on the MoSCoW
method of assigning priority, which specifies that tasks should be split in to Must,
Should, Could and Won’t [6] - for my board I used only the first three. Normal tasks were written on yellow notes, bugs that required fixing went on pink
ones. This systematic approach to project-management ensured that testing was
an integral part of my work-flow which facilitated my desire to utilise extensive
automated testing. My weekly reflections on using the board between September
and December can be found in Appendix A.
Figure 1 is a photo of my task-board in the middle of development. Using a
task-board ensured that I had a quick reference for my current workload, as well
as ensuring that each task was well-defined and of a predictable size (i.e. no task
would require ten-times the amount of work as another).
2.3
2.3.1
Selecting The Right Tools
Architecture
From the outset I decided that I would be developing Press as a web-application.
My primary reason for this was the desire for cross-platform operability - rather
than develop a code-base suitable for only one architecture, developing in the webbrowser would ensure end users would need not worry about platform choices.
6
Figure 1: My task-board
Having defined the scope of the project I was confident that I would be capable
of producing software that fulfilled the initial requirements. Of-course the primary
draw-back to this approach is the number of rendering-engines currently in-use
today - Figure 2 shows the distribution of browser market-share. When building
for the web we must consider all these browsers, as well as a plethora of versions
for each - individually containing various quirks which can affect the operation of
web-applications, as well as the aesthetics of web-pages.
Figure 3 shows the initial system architecture design for Press, alongside the
7
Microsoft IE 11.0
Microsoft IE 8.0
Chrome 40.0
Microsoft IE 9.0
Chrome 39.0
Firefox 35
Microsoft IE 10.0
Other
19%
23%
9%
8%
23%
7%
6%
6%
Figure 2: Browser Market Share Jan-Feb 2015 (rounded) [2]
Figure 3: System Architecture
various technologies and languages used for each area.
8
2.3.2
Languages
Having never deployed a large-scale application with Python I was keen to use it
for the project. Python itself is a mature and refined language with an extensive
community of developers, I was initially drawn to it because of the simplicity of
syntax it employs, and the quality of code that it encourages.
For the client-side, modern web developers have only one option: JavaScript
(JS). I specifically chose a project which would rely heavily on JavaScript as my
previous encounters with the language often led to frustration. I saw this as an
excellent opportunity to learn and develop as a software engineer - by forcing myself to use vanilla JavaScript (that is, without a framework) for a large percentage
of the code-base I would gain a deeper understanding of how contemporary webapplications function. With that in mind I also employed the jQuery JavaScript
framework for higher-level functionality on the client.
JavaScript was initially developed as a light-weight scripting language aimed
at non-programmers, and was designed in only ten days - Brenden Eich (the creator) said of it: “[it] needed to be a silly little brother language [to Java]” [18].
And yet most of the modern web heavily relies on this silly little brother. With
all the rough edges of JavaScript the jQuery framework has enjoyed monumental success with nearly 20% of the entire web using it [12] - the library handles
many cross-browser quirks, enables a cleaner syntax, and contains many common
functions for producing sophisticated web applications.
2.3.3
Web-server Frameworks
In order to focus my efforts on the main goals for the project I decided that using
a framework for the web-application would be best suited to my needs. Rather
than reinvent the wheel I set out to find a framework with a number of features:
1. URL routing and view dispatching (the linking of a URL to a specific
view, and the process of returning the requite data)
2. A template engine in which data and basic HTML fragments are combined
in order to produce complete web-pages
9
3. Object-relational mapping (ORM) so as to reduce the time spent writing
simple database interaction code
Flask is a micro-framework for creating web-applications and is focussed on
a lean code-base without enforcing an extensive set-up [17]. While it features
both URL-routing/view dispatching and a template engine, it lacks an ORM and
requires SQL to be written by hand.
Django is a web framework “for perfectionists with deadlines” [8] containing
all the features outlined above and many more. The focus of the project is to allow
developers to produce high-quality websites in a short space of time, and with my
agile approach to building Press I decided that Django would allow for short development cycles. Although the initial setup takes longer than a framework such
as Flask, the power of Django becomes immediately clear when writing complex
applications - its use of the Model-View-Controller (MVC) paradigm (as an example) ensures that developers write clean, consistent code.
2.4
System Components
In order to facilitate a high-level overview of the system to be developed, I began
by splitting Press into key components. Each of these would require significant
development time and would represent quality end-to-end slices of functionality
[19].
The remainder of this chapter will enumerate each of these components and
discuss in detail their development.
2.4.1
Server-side Code Structure
Experience has taught me that thoughtfully-designed data-structures are of the
highest importance, but the iterative nature of my development process encouraged me to not spend too long thinking, but rather get making.
Django uses the concept of “models” for objects which are mapped to a database
10
by the ORM, as such my application’s primary data objects were to be defined as
models. Django also has an in-built migration manager which is capable of reconciling changes to models with existing data, so I was confident that future revisions
to my design would be easy to incorporate. With that in mind Figure 4 shows the
initial models.
Figure 4: Initial Models
The core model for the application is the Document - this represents content
produced by users. While the title, author, and last-modified properties are self
explanatory the remaining two warrant some explanation. Firstly the status field
represents the current state of the document, usually this is either “draft” or “published” and would allow for access-control based upon who was viewing a user’s
documents.
Secondly the content field: this was to hold all of the document’s data. I
considered various options for storing the main body of content as listed below:
1. Constituent Objects
Composing a document of multiple sub-objects which would represent sections rather than having a single ‘content’ attribute for each document. This
approach (as is shown in Figure 5) would deliver high-cohesion and would
enable me to localise a lot of functionality to Section objects and other subobjects, but I decided that the over-head associated with maintaining such a
structure out-weighed the potential benefits - in my opinion this was overlycomplex.
11
2. Mark-up
Rather than store separate objects in the content attribute, the text produced
by the editor could be translated into a simple mark-up language using tags
such as ∗ ∗ boldtext ∗ ∗ to delineate text attributes. While this would be
more efficient than storing multiple objects, it would require a translation
step which I felt was over-engineering the problem - as no output would use
the mark-up directly.
3. JavaScript Object Notation
Recently the JSON format for the transmission/storing of data has become
popular and so I considered implementing a serialisation step between the
editor’s HTML and the database. Here elements would be translated into
simple dictionary-like objects, then serialised. This would allow for complex JS processing (versus the alternative of simple string manipulation),
and would allow me to store data in a standardised fashion. However the
serialisation step once again appeared to me to be unnecessary - if no output
directly depended upon the JSON, was it worth using?
4. HTML
As the editor would be outputting HTML this seemed like a logical solution. Rather than requiring serialisation or translation the application could
simply store the HTML, and not have to alter it for the output of certain formats. Furthermore I could utilise XML manipulation libraries on the server
to transform the output when necessary, and gain speed increases when not
required to alter the data for output. The primary drawback to this approach
is that the editor would increase in complexity - ensuring that the output
was consistent and efficient would feature in its design.
After considering these options I concluded that either storing the HTML output by the editor directly, or creating consistent objects would be preferable. As
most of the alterations to a document’s content would be made on the client I felt
that the server could trade the cohesion of knowing about a document’s content
with sub-objects for speed - once the HTML is loaded into the browser elements
automatically become objects in the Document Office Model (DOM), accessible
by JS, meaning there was no reason to explicitly mirror this on the server. I finally
concluded that a document’s content attribute would store the HTML produced
by the editor.
12
Figure 5: Document Sub-object Architecture
2.4.2
Client-side Code Structure
JavaScript programming in the browser is event-driven, as such the vast majority
of functionality is invoked following events such as a user clicking a button, or
the page finishing loading. Figure 6 is a generic model of the structure of event
binding and handling. After the document is loaded, JavaScript is given access
to the DOM which represents the page’s HTML and structure, at which point
all events are bound to their corresponding elements, before transitioning into
a waiting state, in which the browser listens for any events. When a user action
triggers an event the browser invokes any handlers which are bound to the element
causing the event, passing an event object with detailed parameters regarding the
event.
Most JS code is written in these handlers as they offer a natural starting-point
for dealing with user interaction. If the event doesn’t require communication with
the server the handler may update some variables and/or manipulate elements on
the page. When this happens we transition to the DOM Updated state which
immediately either returns to the waiting state, or triggers a fresh event binding.
Refreshing the binding will take-place when the handler has altered the DOM,
and is triggered by custom JS written for Press - it may also pass a context to the
event binder which ensures only the changed elements are refreshed, rather than
13
Figure 6: Browser event flow-chart
14
the entire page.
If the handler requires access to the server to save or retrieve data it invokes
the Asynchronous JavaScript and XML HTTP Request (AJAX) handler, which in
turn makes a request to the server and returns any response to a callback function,
which then may be used in the original event handler. For security AJAX requests
in Press include a cross-site request-forgery (CSRF) token which is then verified
on the server - this ensures that a malicious attacker cannot invoke requests to
Press from another domain.
“In a CSRF attack, a malicious site instructs a victim’s browser to send a
request to an honest site, as if the request were part of the victim’s interaction with
the honest site, leveraging the victim’s network connectivity and the browser’s
state, such as cookies, to disrupt the integrity of the victim’s session with the
honest site” [3]. CSRF tokens work by setting a cookie (a small key/value pair)
on the client’s machine, and having the value of said cookie sent to the server
with every request. As sites can only access cookies set by themselves we can
be confident in our requests’ origins and prevent the exploitation of this kind of
attack.
2.5
Editor
The key aspect of this project is the editor. Current solutions all lack editors which
meet the needs of modern publishing no matter the quality of their final output,
and so I knew that producing an excellent editor would be paramount.
2.5.1
The Ideal Output
Before beginning development I set-out to define the ideal output of the editor in
terms of the HTML that would be produced. The first goal was to have excellent semantics which “is about HTML elements that describe the type of content they contain” [5] - a topic which has gained more traction in recent years as
developers have aimed to make content more accessible to software processing
techniques. Secondly I would aim for Simple & Clean Code containing no un-
15
necessary mark-up, and conforming to the World Wide Web Consortium’s (W3C)
HTML coding standards [20]. Figure 7 shows the difference between mark-up
which is not semantic, and that which is. Rather than use div (dividing block) elements for instance, the section tag is used to delineate sections of content. Notice
too that the second example features no CSS styling - this decoupling ensures the
capacity to easily change all style rules from a separate CSS definition (more on
this later).
<!-- Un-semantic HTML -->
<div id="section-1">
<h1>My Section</h1>
<p>Content sits in paragraph elements which are
<span style="text-style:italic;">exceedingly</span>
semantic, and <span style="font-weight:bold;">very</span>
clean.</p>
</div>
<!-- Semantic HTML -->
<section>
<h2>My Section</h2>
<p>Content sits in paragraph elements which are
<em>exceedingly</em> semantic, and
<strong>very</strong> clean.</p>
</section>
Figure 7: Comparison of un-semantic and semantic HTML
2.5.2
WYSIWYG Editing
One of the very first features of Press that I conceived of was the what-you-seeis-what-you-get (WYSIWYG) editor. Creating an easy-to-learn editor suitable
for the non-technical user, but capable of incorporating powerful formatting technologies led me to conclude that using the WYSIWYG paradigm would be most
desirable. The immediate user-feedback provided by such an editor (e.g. bold text
immediately turning bold) would reduce the learning-curve for users.
Furthermore I would be able to leverage my users’ existing knowledge from
past experience, I therefore designed formatting icons which relied on common
16
Figure 8: The editor’s formatting buttons
design principals. Figure 8 shows the icons used in the final editor. A survey
was conducted to ensure that the icons were recognisable by the general public for this a range of people were asked to assign the function of each button having never used Press, stating only that they should think within the context of a
word-processor. The results were encouraging in demonstrating that 77.5% of respondents correctly classified each button - appendix B shows the survey results
in full.
2.5.3
Word-processing Technologies
In order to facilitate the WYSIWIG editor I had to explore various options available to me in the latest specification of HTML - as I required full control over my
editor two choices presented themselves.
My initial inspiration for the editor was the word-processor provided by Google
Docs in which users can produce complex documents within the browser. I naı̈vely
assumed that the software utilised a heavily-customised version of the contentEditable attribute discussed in the next paragraph, but upon investigation discovered
a vastly more complex solution: Google’s engineers had written a rendering and
layout engine entirely in JavaScript - nothing was as it seemed, even the user’s
caret (cursor when editing text) had been faked using CSS [9]. Their solution
utilises the HTML5 canvas tag which can be used to draw graphics via JavaScript
[14] - although comprehensive this approach would require vastly more development time than was available.
The second was the contentEditable attribute introduced in HTML5 which
“can transform your web page into a full and fast rich-text editor” [15] - at first
glance it would seem to be a ready-made solution as a developer need only enable
contentEditable and the browser handles the rest. However this attribute is deceptively complex, having been implemented to varying standards across all the
major browsers, without extra processing there is no way to accurately predict the
17
output of the same actions applied to different browsers. Table 1 shows the output HTML from rendering engines used across all major browsers when pressing
the Enter key once inside an element with contentEditable turned on - as we can
see the code is different for every engine. This variability would mean that much
processing of the output would have to be employed in order to achieve consistent
mark-up.
Webkit Blink Gecko
Titan
<br/> <br> <p><br><p> <p>< /p>
Table 1: Resulting HTML from pressing the Enter key in a contentEditableenabled element across rendering engines
Despite this obvious challenge posed by contentEditable, I decided that it was
a better option than starting from scratch as Google had done - rather than implement fundamental characteristics of a text-editor (such as text-selection and cursor
movement), the majority of my time could be spent implementing slightly-higher
level functionality.
2.5.4
Learning to Type
To handle the inconsistencies posed by contentEditable JavaScript code intercepts
every key-press made within the editor - these events can then be processed and
analysed to ensure they produce output conforming to the pre-defined standard.
To illustrate this process below is the simplified pseudo-code for processing the
Enter key:
selection = getUserSelection()
parent
= selection.getParentElement()
if( parent ):
moveSelectionAfter( parent )
contentAfterSelectionStart = selection.contents()
if( parent.text is empty ):
18
if( parent is <li> ):
moveOutOfList()
createParagraph()
else if( parent is <figure> ):
createParagraph()
else:
createSection()
else if ( contentAfterSelectionStart is empty ):
createParagraph()
else:
if( selection.isAtEndOfElement() ):
insertParagraph()
else:
splitElementInTwo()
This algorithm demonstrates the number of ‘if-then’ cases that are introduced
when dealing with complex documents, and indeed the simplified pseudo-code
hides many more for clarity. For instance this algorithm first checks if the selection’s parent element is empty and if so creates different new elements based upon
the previous element. This illustrates the composite functions of the enter key it is responsible for creating new paragraphs, moving out of lists, creating new
sections, and splitting elements in two when the caret is in the middle of some
content. Combining all this functionality into one key may sound complex from a
user’s point of view, but text editors have done so for decades, meaning that it is
now the standard.
Further to implementing basic typing functions, a number of other cases presented themselves while implementing the editor. Firstly is the notion of pasting
content. Unfortunately many modern browsers have attempted to be ‘helpful’
in their implementations of contentEditable, and will actually convert the pasted
content into valid HTML which matches the content’s style. However this always
results in a multitude of excess elements and in-line styles (see below) - these
extra elements lead to problems when aiming for highly-semantic, yet efficient
output.
19
As a brief aside on in-line styles: these are styling rules applied directly in
the HTML, and is a practise which is highly discouraged by the web-development
community for good reason. For instance should a user wish to change the style
of multiple elements, if their style is redefined for each element in the HTML the
user must make updates to every one.
In order to mitigate this functionality I had to intercept paste events to inspect
the content. In Press the content is simply stripped of all styling and reduced to
its text-only version, I came to the conclusion that this was the best option after
using Press to write complex documents myself. Without doing this I would paste
in blocks of text from various sources and end up with different fonts and colours
throughout my document.
Another behaviour that has to be accounted for is that of the type-over event.
This occurs when a user selects part of a document and then presses another
key. This situation is deceptively complex - while handling type-overs that occur within the boundaries of a single element is rudimentary (and to an extent
those that occur in contiguous elements of the same type), selections which span
content contained by elements of differing types introduces added complications.
Furthermore if a user begins their selection of (for example) text in the middle
of a paragraph and then proceeds to select the content which follows in different
elements, and then types-over we cannot simply remove the starting paragraph,
we must consider only that which is selected. In Press these intricacies are once
again handled by a number of ‘if-else’ clauses - a situation only slightly mitigated
by my enforcing of simple HTML.
2.5.5
Uploading & Managing Images
A core feature of the editor is that of using images in documents, to handle the
uploading of images in Press the concept of a media manager was implemented a repository for all the images uploaded by a user available when editing a document. Figure 9 shows the manager in Press which is animated in to the left of the
document when a user clicks the “Insert Image” button. Notice the second image
in the top row is in its hover state i.e. the cursor is placed over it, here we see the
actions available to the user: edit and insert. Clicking the first shows the user the
whole image, as well as allowing them to edit meta-data, while the second places
20
the image into the document.
Figure 9: The inline media manager
To upload new images users can browse their computer after clicking the Upload button, images are then uploaded to the server via AJAX and automatically
added to the media grid for immediate use.
Once images have been inserted users can mark them as either supplementary
or focus images - the former represents images that only supplement the text,
such as a photo of someone smiling when writing about happiness, while the
latter represents images which contribute to the content as stand-alone entities, a
scientific diagram would be an example of such an image. This distinction is used
in later processing of the document as will be described in the next section.
Finally users can also specify the alignment and position of images - allowing
for in-line floating images which cause text to wrap around them, or block-level
images which occupy distinct portions of each medium they are used in.
21
2.5.6
Review Mode
The last feature for the editor was review mode - the ability to annotate documents
in-line, and invite collaborators to do the same.
Figure 10: A document in review mode
In this mode users are able to select elements in the document and write notes
in a sidebar. Figure 10 shows a document in review mode with a single note
annotating the first paragraph. Above the annotation we see a box entitled Invite
people to review - the link below enables anyone to annotate the document which
was inspired by the Google Docs feature of sharing a link to a document which
enables others to edit it.
In Press those who receive a review link need not have an account. In order
to reduce friction for those invited to review documents, Press simply asks for a
name and email address. Figure 11 shows the page that users are directed to when
following an invitation link.
22
Figure 11: An invitation to review
2.6
Online Views
Allowing users to view their content in the browser was an essential requirement
for the project - certain views such as the slide-show would be entirely dependant
on the browser, while others such as the textbook and handout would primarily be
utilised off-line. This section explores each view available in Press.
2.6.1
Textbooks
The simplest of the online views is the textbook - here content is output exactly
as it appears in the editor in long-form text. Ensuring users write their content
in this format means that no transforms are required to the structure, Press need
only alter the style. Complexity is only introduced when generating the off-line
version of this format as is to be described later.
2.6.2
Slide-shows
Although the raw document HTML as output by the editor suffices for textbooks,
slide-shows bring a new set of challenges that cannot be adequately addressed
using the same mark-up. Rather than attempt to force the HTML into working
23
in the slide-show context in an un-semantic fashion, I decided that a conversion
would have to take place.
<section>
<h2>My Title</h2>
<p>Once upon a midnight
dreary, while I pondered
weak and weary. Over many
a quaint and curious
volume of forgotten lore.
</p>
</section>
<li>
<h2>My Title</h2>
<p>Once upon a midnight
dreary, while I pondered
weak and weary.</p>
<p>Over many a quaint and
curious volume of forgotten
lore.</p>
</li>
Figure 12: Comparison of document HTML (left) and converted slide-show
HTML (right)
Figure 12 shows the difference in mark-up. Key distinctions include the change
of sections to list-items (which themselves represent slides), although each section
may be represented by multiple list-items. Note also the splitting of the paragraph
element into multiple paragraphs - this approach prevents slides accumulating
large blocks of uninterrupted text and, in later testing, proved to produce slides
which looked hand-made.
While the algorithm summarised above adequately transforms the basic document HTML into useful and semantic slide-show HTML, a further consideration
of the amount of content-per-slide or slide density, must be taken in to account. In
order to achieve quality output Press needs to decide how to split content across
multiple slides. There solution was to assign a density to each element in a slideshow:
Density =
length(C)
∗ Mt
(L + 1)
Where C is the element’s text content, L is the number of line-breaks Mt is a
pre-defined multiplier for the element’s type. Slides then accumulate density as
elements are added to them, and are split when they reach a pre-defined maximum.
Assigning the correct multipliers for each element, and selecting a slide maximum
24
was a matter of trial and error, tweaking the numbers until they generated quality
results. The basic idea is that elements that occupy more space-per-text-character
should have a higher multiplier - paragraphs have lower multipliers than tables for
instance, as tables have higher margins and padding.
One subtlety with online slide-shows is that all positioning and sizing must be
relative. Programs such as Microsoft’s PowerPoint simply restrict the user to a set
size of slide and thus greatly simplify the creation process. With Press however
I wanted to create a solution that would look beautiful across all screen sizes.
In order to achieve this elements are positioned and scaled relative to the screen
on which they are being displayed - positioning is achieved using percentagebased layouts (as opposed to the far more widely-used pixel-based.) This method
ensures that, for example, slide titles always occupy at least 15% of the screen.
Element sizing is controlled using CSS media queries in which different size fonts
and layout containers are used based on the dimensions of the screen.
2.6.3
Handouts
Press aims to produce handouts that mirror the content of the slide-show, but
which are not a simple listing of slides with space for notes. Traditional slideshows are not designed to be printed, they work well on a large screen where
animations (both of the slides and of GIFs) can take place, and where excessive colours don’t incur high-printing costs. Alongside the issue of animations,
slide-shows also feature text-sizing and layouts which do not translate well to the
printed-page.
With this in mind I set the clear definition of a good handout as being complementary to the slide-show, but aware of the difference in medium. To generate
handouts in Press the software first generates the slide-show HTML, then outputs
it with alternate CSS designed for handouts. This approach produces content that
clearly matches that which is show on the slides, but which is better-suited for
paper. Figure 13 illustrates the results and clearly demonstrates both the spacesavings, as well as the readability of the different formats.
25
Figure 13: The slides compared to the handout
2.7
Off-line Views
Unfortunately web-browsers are not well-equipped for the task of translating the
unbounded, low-pixel-density box that is the web-page to printed paper. For many
years web-designers have been able to specify print style-sheets used specifically
for this task, although the majority focus on hiding unnecessary images or removing link colour and other features which don’t translate to the print medium.
Furthermore each browser implements printing differently and user-specified values may over-ride those used in custom style-sheets.
I therefore decided that generating my own PDFs to be down-loaded by users
would result in the most easy-to-control and consistent output. To achieve this
Press makes use of the excellent Python library XHTML2PDF - a set of tools
designed for translating HTML into the PDF format. To ensure a high-quality
of output Press uses custom print style-sheets for both textbooks and hand-outs,
utilising library commands which enabled it to define printing rules. For example:
@page {
size: a4 portrait;
26
@frame content_frame {
left: 50pt;
width: 482pt;
top: 350pt;
height: 717pt;
}
}
h2 {
-pdf-keep-with-next: true;
}
The above code indicates that each page should be of size A4 and in portrait,
as well as specifying the margins for the content. Second-level headings are also
bound to the next element meaning that headings never appear at the bottom of
one page with their content cut off on to the next, therefore generating a far higherquality of output. Other features of the printing include title-page generation and
table-of-contents production in which headings and sub-headings are extracted
from documents in order to produce a contents page for a textbook.
This fine-grained control enabled Press to maintain the high standard set for
the various mediums of the project at the outset. In testing an extended period
of time was spent tweaking various print settings in order to achieve high-fidelity
output.
2.8
Slide-show Editor
Even with the most comprehensive algorithm for converting between long-form
content and slide-shows automatically I concluded that greater customisation was
required. In order to achieve this Press features an in-browser slide-show editor in
the form of a stripped-down version of Microsoft’s PowerPoint, or Google Doc’s
Slides.
As noted above the slide-show layouts are designed using relative positions
27
and scales, however presenting a simple and consistent canvas to the user was a
key design element for the editor. Slides are displayed using a 4:3 aspect ratio for
two reasons: firstly this is the standard size used in the most popular slide-show
packages and would therefore be familiar to users, and secondly it is a common
ratio for interactive whiteboards used in real classrooms, making it the perfect size
for the majority of users.
An interesting question that posed itself during the development of the slideshow editor was that of saving the output; a number of options presented themselves for storing the edits made to a document’s slide-show:
1. Store the changed slide-show HTML
While this would be rudimentary to implement, it would deviate from the
data structure outlined above. In this scenario changes to the document’s
HTML would not be reflected in the slide-show. For this reason I decided
this would not be feasible.
2. Store the changes in the corresponding document HTML
This approach would solve the issue caused by saving the slide-show HTML,
but would require a reversing of the document-to-slide-show conversion algorithm. This method was used initially resulted in document HTML that
was exceedingly convoluted and increasingly un-semantic.
3. A new data-structure
Instead of directly altering the document’s content the changes could be
stored in a separate object named SlideshowEdits - simple commands such
as “move title down 10 pixels” could then be combined with document
HTML to produce slide-show mark-up.
Finally the new data-structure approach was decided upon. This would allow
for the retention of good semantics for document content, as well as ensuring that
edits made to the document would be reflected in slide-shows.
When a user makes a change to a slide–show the affected element is marked
as having changed, the reference is stored as the element type, and index at which
it occurs e.g. the third paragraph is referenced as
element : p, index : 2
28
counting from zero. Changes to animations or position are then stored with this
reference. When saved this reference allows the server-side processor to assign an
ID to the element in the document HTML such as “edited-element-0-1” which
is used to refer to the element henceforth. Saving an ID in this way ensures that
changes to the document structure don’t over-write alterations to the slide-show.
{
"element_type": "H2",
"element_index": 0,
"animations": [
{
"duration": "200",
"index": 0,
"trigger": "click",
"type": "fade-in"
}
],
"element": "edited-element-1-0"
}
Figure 14: JSON for storing slide-show changes
Figure 14 shows the resulting JavaScript Object Notation (JSON) that is used
to store changes for slide-shows. In this example the first level-two heading will
have a fade-in animation applied to it when used in the slide-show.
2.9
Slide-show Controller
A late addition to the project was the ability to control slide-shows from another
device such as a web-browser on a mobile phone or another computer entirely.
After some user feedback it became clear that while simple keyboard navigation
was suitable for small classrooms, in large lecture theatres it was a sub-optimal
solution.
In order to achieve this the system’s architecture was revised as is shown in
Figure 15. Here we see the incorporation of a Node.js server. Node.js is a “platform built on Chrome’s JavaScript runtime for easily building fast, scalable net29
Figure 15: Revised System Architecture
work applications” [7] in which software is written in JavaScript.
Alongside Node.js I used the Socket.io library which “enables real-time bidirectional event-based communication” [10] - a set of tools specifically designed
for leveraging web-sockets. Web-sockets (or just sockets) allow for interactive
communication between the client and server [16] without the requirement for
constant polling from the client. This is a deviation from the standard Hypertext
Transfer Protocol/Transmission Control Protocol (HTTP/TCP) model of the web,
in which clients close connections immediately upon receiving a response. Sockets also enable low-latency transmission of data as (unlike HTTP) the technology
does not enforce handshaking for every request.
The steps required to successfully control a slide-show are as follows:
1. User opens the slide-show on the computer to be used for presenting. At
this point the slide-show keeps a connection to the Node.js server open and
listens for events in the form “next slide” and “previous slide”
2. User opens the controller page on another device such as a mobile phone.
30
The controller then registers with the Node.js server and awaits user input
3. User presses one of the controller buttons, causing the page to dispatch a
request to the Node.js server, indicating which button was pressed
4. The Node.js server routes the event to the correct slide-show page
5. The slide-show receives the event and triggers the correct action
A final feature of the controller is the ability to control multiple slide-show
instances at once. A user may wish to display their slides on multiple devices and
maintain control over all of them concurrently. Potential applications range from
complex classroom layouts with multiple screens to support for remote-teaching
sessions. The user need only open the slide-show on each device, then use a single
controller to control all instances.
31
3
Testing
This chapter will explore the various testing techniques employed throughout the
project and assess their impact and results.
3.1
Unit Testing
The majority of testing was done using unit tests - I was drawn to using this
approach as it forces the developer to (in my opinion) write cleaner code. In order
to have testable units developers are discouraged from writing long, un-cohesive
functions, this makes the process of debugging much easier.
To facilitate this I made use of the QUnit library [11] on the client-side, and
Python’s UnitTest module on the server.
3.1.1
Client
In total there were 108 unit tests for my JavaScript with 79% code-coverage.
While I would have preferred this to be total coverage, due to the nature of some of
the code, quality unit tests were impractical. For the remaining code I employed
further system testing (see below).
3.1.2
Server
In total there were 65 unit tests for my Python with 93% code-coverage. Again full
coverage was impeded by the structure of some of my code. In this instance this
is more likely due to my own haste in writing certain blocks of code, combined
with a lack of refactoring in specific areas.
32
3.2
System Testing
Google Chrome has a suite of excellent profiling tools for analysing web-pages,
Figure 16 shows the time taken for each task when loading the editor page. The
scripting portion is of most interest here as it represents the portion caused by
code written for Press - the 121ms or so taken to complete all the event-binding
and initial set-up.
Figure 16: Editor page time allocation
Figure 17: BBC News home-page time allocation
By way of comparison figure 17 indicates the distribution when loading the
BBC news home page on the same machine. The editor page has ∼66KB of JS
33
which is around 45% the size of BBC (which has ∼145KB). Adjusting for this
difference the BBC scripts 66KB in ∼104MS - just 17MS faster than Press.
A common problem with modern, complex JS is when code forces the browser
to ‘re-paint’ - in which the DOM is processed a second-time due to (among other
things) alterations made by the JS [13], this causes sub-optimal performance and
so I ensured that Press caused no re-paints by moving DOM changes into the
templates rendered by Django, making few structural changes in the JS. Figure 18
illustrates the difference between a page-load for the BBC News home-page, and
the Press editor, with the re-paint highlighted for the BBC.
Figure 18: Above: BBC News home-page rendering break-down. Below: Press
editor rendering-breakdown.
With this in mind I was happy that my code-base was sufficiently optimal.
34
4
Evaluation
Throughout the project I was in contact with a number of users who were kindenough to help evaluate my work. Firstly the chief writer for EBradbury (one
of the resource collections produced by Rocket Education) helped me clarify the
aims and requirements for the project from the outset. During the development of
the project she helped alpha-test every feature before they moved into beta-testing,
with which she also helped. Naturally having such an impact on the direction of
the product meant she was predisposed to like the final outcome, and so a group of
teachers was engaged to help beta-test in the later stages of development. At the
end of beta-testing the group was asked to complete an extended survey in order
to evaluate the project, the results were overwhelmingly positive and confirmed
Press was a success (the results of this survey are summarised in Appendix C).
During the final months of development the entirety of EBradbury’s content
was imported into Press, and the resulting artefacts were deployed in to the production environment. Prior to introducing the new resources I expected to see
little if any change in the engagement of our users, however an analysis of active
sessions (a series of actions leading to a goal such as accessing a resource) among
an isolated cohort of users demonstrates higher engagement after the introduction
of Press resources. Figure 19 shows a graph of sessions between January and
April, with Press resources having been introduced on the 15th February.
Figure 19: Active session cohort analysis with the introduction of Press-generated
resources highlighted
Other factors and changes were closely controlled during this time-frame, and
marketing efforts remained steady, so lacking evidence to contradict the theory,
it would seem that users spend more time looking at resources created by Press,
possibly due in part to the introduction of the extra ‘handout’ format. Furthermore
35
no users contacted support with complaints about the new resources during the
period, indicating that they match the hand-made versions closely enough, so as
not to cause alarm.
Using the agile methodology for the project, and specifically the task-board
was an interesting exploration of a technique that was completely foreign to me.
Enforcing a strict process for managing the workload allowed me to make the
most efficient use of my time. Furthermore due to the dedicated ‘testing’ column
I never forgot to test new code, and while the results are intangible, I certainly feel
that this approach has led me to produce more reliable code.
36
5
Conclusion
Having created the vast majority of my previous web-applications using only PHP
I can say that I am now a Django/Python convert. Press has demonstrated to me
that the tool-set provided by Django is exceedingly powerful and is one I will be
utilising to great length in the future.
Although more hours than I care to count were spent debugging JavaScript,
I’m happy that I choose a project so heavily-reliant on the language. While jQuery
provides an excellent path to start the journey into client-side browser-scripting, a
solid knowledge of the language with which it is written has come to benefit me
greatly.
My foray into Node.js was as interesting as it was useful. I am of the opinion
that the best way to learn is to simply attempt to build - in the case of Node.js I was
correct - and as this emergent technology comes to play a bigger role in the webdevelopment landscape [4] I shall be better equipped to deal with the challenges
facing modern programming.
While the initial target-market for Press was the education industry I am now
inclined to believe that it has applications outside of this base. Having made use
of Press for the project’s seminar for instance, it is clear that it provides a streamlined process for the production of content which is to be used across varying
mediums. One of my evaluation users also commented that they had used Press
to give a presentation at a staff meeting which speaks to the perceived reliability
of the project.
As is always the case the estimated complexity of most aspects of my work
was lower than the reality, but thanks to the use of my task-board I was able to
realise all of my initial goals. Overall I’m confident that I achieved all the aims I
set out to reach at the start of the project. Moreover there are a number of features
absent from the initial design which are now core aspects of Press - the slideshow controller is good example of this, and one which led to not only a useful
feature, but an entirely different avenue of personal development in learning a new
platform.
Over the coming months I intend to refine Press and deploy it as a stand-alone
37
product for Rocket Education, I am therefore happy to report that my project was
a success.
38
Appendices
A
Taskboard Notes
A.1
Week 1 - October 26th
1. I’m up and running quite successfully! I’m finding that forcing myself to
write down a set of tasks and only working on those tasks I’ve written out is
very useful - my usual method of working is to attack a problem, discover
another problem, and fall down a rabbit hole. Limiting myself to working on
specific, more importantly measurable tasks means I’m getting more done
and prioritising work much better.
2. I’m questioning the usefulness of the completed column - if tasks no longer
require active engagement why should they take up space on the board?
A.2
Week 2 - November 3rd
1. Re my point in week 1 about the completed column: the satisfaction from
seeing tasks in the completed column provides a good sense of progress, and
the lifetime of the phase (1 day) means I don’t end up in a pat-on-the-back
cycle!
2. My seminar is this Friday and as I’m intending on using my project to do
the seminar I’ve been working overtime - again being forced to write tasks
down on individual cards provides a great level of clarity and I think it’s
meaning I can work faster.
3. Picking the appropriate row for each task isn’t as hard as I had anticipated
- at least between the Must and Could columns. My discussions with my
supervisor mean I’m pretty clear on the features that should go in these two
columns. As for Should I’m asking the question “Is it essential?” for each
task - if the answer is no then it goes in should, otherwise it’s a must.
39
A.3
Week 3 - November 10th
1. I added my first bugs this week and was intrigued by the result: instead of
appearing like ordinary tasks because of their colour every time I looked at
the board I was drawn to them. This meant that I was more inclined to work
on them in order to remove the “distraction” as it were. I think this is a good
thing as it ensures you’re focussed on removing bugs in the system before
moving onto new features.
A.4
Week 4 - November 17th
1. This week I spent a couple of evenings at uni working on my project, and
immediately realised that without my board I had no frame of reference for
tasks - something I didn’t anticipate initially, luckily I was able to work on
some tasks I remembered. When I got home I had to update the board.
2. I’m finding writing tasks much easier now, initially I had to keep looking
at the control task but now I feel as though I’m actually living the practise
rather than imitating it!
A.5
Week 5 - November 24th
1. This week I updated my Python version which inadvertently broke half my
code...this is reflected in the primarily pink board! The board helped keep a
lid on my panic as I saw different parts of my code breaking, even if it was
daunting to see so much pink.
2. While I’m primarily bug-fixing this week I feel as though the pink colour
commands a disproportionate amount of attention, and prevents me from
progressing with other tasks, I’ll see how this pans out in future weeks.
A.6
Week 6 - December 1st
1. I didn’t get a huge amount of work done this week due to being busy with
other things, and the board made me feel guilty! On reflection I suppose
40
that’s a good thing, as it makes me want to work extra hard to get the tasks
off the board.
2. I scrapped a task from the Waiting/Could section this week that had been
there since day 1 - “Subject [content management system] with document
management” because I no longer felt it was necessary. I also decided it was
overly vague and probably wasn’t the best task (especially with reference to
my control task)
A.7
Week 7 - December 8th
1. My last entry! This week I was able to add a number of “should” and
“could” features as much of my core software is complete - this breakdown
of priority is useful in making sure I’m completing the most important tasks
(as I predicted it would be)
2. I’ve also spotted that there are no bugs in the photo of the board I just took,
which leads me to conclude my software it bug free!
B
UI Survey
Button
Bold
Italic
H2
H3
List
Numbered-list
Code
Image
Link
Reference
Most Common Response
bold
italic
heading 2
heading 3
bullet points
number point list
markup
insert image
link
quote
% Correct
100
70
60
60
100
100
50
100
75
60
Number of respondants: 25, Average percentage correct: 77.5%
41
C
Final Evaluation-user Survey
The first fifteen questions were answered on a scale of one to ten. The first three
featured a scale from ‘Not at all’ at zero, to ‘Definitely’ at ten. The rest go from
‘Strongly Disagree’ at zero, to ‘Strongly Agree’ at ten.
42
43
44
The final two questions were text-based:
How would you describe Press to a teacher?
1. Tom has made a website that removes the need for copying and pasting
content between software packages and which focusses on the content rather
than the tools you chose to make them. Instead of starting from scratch
for workbooks and presentations it lets you get to work and automatically
makes each by itself. I would highly recommend this.
2. Create textbooks online and build slideshows that work online too with
print-outs for students.
3. A place to make and share classroom resources
4. An all in one solution for keeping documents together which saves oodles
of time!
5. Google docs meets iA writer!
6. Think if dropbox was built in to publisher and powerpoint
Any comments on any aspect of Press?
1. Slideshow making is just magic, so many students have said they prefer my
new slides to the old ones. The transition to using it was also really simple,
and I like that keeping references is built-in, although I’d like to be able to
add footnotes to textbook pages if possible. Great stuff as ever!
2. Clean and simple but capable of making things look excellent!!
3. It’s amazing how little you have to think when making content now, before
I had to dedicate lots of time to making PowerPoints etc. but now I write it
in Press and it’s ready to use immediately
4. I think the animations and customisation of the powerpoints should be more
varied, they look good but if there were more options it would be great.
Love the editor because it’s distraction free. And how you don’t need special
software to run it. And the controller for powerpoints is fab
45
5. absolutely love the slides and how they just get generated, worth it just for
this! and the handouts must have saved me a whole bunch of money for
printing already!
6. No response
46
References
[1] D.J. Anderson. Kanban. Blue Hole Press, 2010.
[2] Net Applications.
Desktop browser version market share.
http:
//www.netmarketshare.com/browser-market-share.aspx?qprid=
2&qpcustomd=0&qptimeframe=Y, 2015. Accessed: 2015-04-04.
[3] Adam Barth, Collin Jackson, and John C. Mitchell. Robust defenses for
cross-site request forgery. In Proceedings of the 15th ACM Conference on
Computer and Communications Security, CCS ’08, pages 75–88, New York,
NY, USA, 2008. ACM.
[4] Donnie Berkholz.
Github language trends and the fragmenting landscape.
http://redmonk.com/dberkholz/2014/05/02/
github-language-trends-and-the-fragmenting-landscape/.
Accessed: 2015-04-04.
[5] A. Bradford. HTML5 Mastery: Semantics, Standards, and Styling. Apress,
Berkeley, CA, 2011.
[6] Kevin Brennan. A Guide to the Business Analysis Body of Knowledge. International Institute of Business Analysis, 2009.
[7] Mike Cantelon, TJ Holowaychuk, Nathan Rajlich, and Marc Harter. Node.
js in Action. Manning, 2014.
[8] Django Software Foundation. Django the webframework for perfectionists with deadlines. https://www.djangoproject.com, 2015. Accessed:
2015-03-19.
[9] Jeff Harris.
What’s different about the new google
docs?
http://googledrive.blogspot.co.uk/2010/05/
whats-different-about-new-google-docs.html. Accessed: 2015-0325.
[10] Automattic Inc. Socket.io. http://socket.io, 2015. Accessed: 2015-0404.
[11] The jQuery Foundation. Qunit. https://qunitjs.com. Accessed: 201503-26.
47
[12] Gangis Khan. jquery usage statistics. http://trends.builtwith.com/
javascript/jQuery. Accessed: 2015-03-24.
[13] Paul Lewis. Avoiding unnecessary paints. http://www.html5rocks.com/
en/tutorials/speed/unnecessary-paints/. Accessed: 2015-03-26.
[14] Mozilla Developer Network. Canvas api. https://developer.mozilla.
org/en-US/docs/Web/API/Canvas_API. Accessed: 2015-03-25.
[15] Mozilla Developer Network. Content editable. https://developer.
mozilla.org/en-US/docs/Web/Guide/HTML/Content_Editable. Accessed: 2015-03-25.
[16] Mozilla Developer Network. Websockets. https://developer.mozilla.
org/en-US/docs/WebSockets, 2015. Accessed: 2015-04-04.
[17] Armin Ronacher. Flask - web development, one drop at a time. http:
//flask.pocoo.org. Accessed: 2015-03-24.
[18] Charles Severance. Javascript: Designing a language in 10 days. Computer,
45(2):7–8, feb 2012.
[19] T Stober. Agile Software Development Best Practices for Large Software
Development Projects. Springer eBooks, Berlin, Heidelberg, 2010.
[20] W3C. Html5 - a vocabulary and associated apis for html and xhtml. http:
//www.w3.org/TR/html5/. Accessed: 2015-03-25.
48