SlideShare a Scribd company logo
1 of 79
Download to read offline
FICTION AUTHORING
Enrollment No. - 9503954, 9103471
Name of Students - Aahana Tomar, Vaidik Kapoor
Name of Supervisor - Prof. Sanjay Goel
May 2013
Submitted in complete fulfillment of the Degree of
Bachelor of Technology
in
Information Technology & Computer Science Engineering
Department of Computer Science Engineering & Information Technology
Jaypee Insititue of Information Technology, NOIDA
1
TABLE OF CONTENTS
Chapter Number Topic Page Number
Cover Page 1
Table of Contents 2
Student Declaration 4
Certificate from Supervisor 5
Acknowledgment 6
Summary 7
List of Figures 8
List of Tables 9
List of Symbols and Acronyms 10
Chapter 1 Introduction 11 - 19
1.1 General Introduction
1.2 Problem Statement
1.3 Empirical Study
1.4 Solution Approach
1.5 Approach to problem in terms of
technology and platform to be used.
1.6 Support for Novelty
Chapter 2 Literature Survey 20 - 31
2.1 List of all the sources for formulation of
problem statement
2.2 Summary of Relevant Papers
Chapter 3 Analysis, Design and Modeling 32 - 44
3.1 Overall Description of the Project
3.2 Functional Requirements
3.3 Non-Functional Requirements
3.4 Logical Database Requirements
2
3.5 Design Diagrams
3.6 Risk Analysis
3.7 Risk Mitigation Plan
Chapter 4 Implementation Details 45 - 56
4.1 Implementation Details and Issues
4.2 Testing
Chapter 5 Findings & Conclusion 57
5.1 Findings
5.2 Conclusion
5.3 Future Work
References 58
Appendices 59 - 70
Appendix A – Work Breakdown Structure
Appendix B – Report of Deeper Analysis of
Existing Tools
Appendix C – Functional Prototypes as Proof of
Concept
Appendix D – Validation of Application Model
and Early Prototypes
3
DECLARATION
We, hereby, declare that this submission is our own work and that, to the best of our knowledge and
belief, it contains no material previously published or written by another person nor material which has
been accepted for the award of any other degree or diploma of the university or other institute of higher
learning, except where due acknowledgment has been made in the text.
Place:
Date:
Signature:
Name: Aahana Tomar, Vaidik Kapoor
Enrollment No.: 9503954, 9103471
4
CERTIFICATE
This is to certify that the work titled “Fiction Authoring” submitted by “Aahana Tomar” & “Vaidik
Kapoor” in partial fulfillment for the award of degree of “Bachelor of Technology” of “Jaypee Institute
of Information Technology University, Noida” has been carried out under my supervision. This work
has not been submitted partially or wholly to any other University or Institute for the award of this or
any other degree or diploma.
Signature of Supervisor:
Name of Supervisor:
Designation:
Date:
Prof. Sanjay Goel
Head of Department (CSE/IT)
5
ACKNOWLEDGEMENT
First and foremost, I would like to thank Prof. Sanjay Goel, our project supervisor. We are immensely
grateful for all the guidance he has given us. His direction was essential to shape our project. We
humbly thank him for all his patience as we worked during the semester.
We would also like to thank Arshiya Lekhi for voluntarily participating in a writing exercise that helped
us understand challenges people face while writing collaboratively.
And last, but not the least, we would like to thank all our peers who shared their suggestions and
criticisms as our project progressed.
Signature of student:
Name of student:
Enrollment Number:
Date:
Aahana Tomar, Vaidik Kapoor
9503954, 9103471
6
SUMMARY
Our project, ‘Fiction Authoring’, is an application which comprises set of tools for book authors
(specifically fiction authors) to assist them with collaboratively planning their stories, helping them
with their cognitive processes and authoring the complete book. This tool will be a web service and
will be mobile compatible. We observed that their aren't enough tools to assist authors with writing and
planning their books effectively. In addition to that, there are existing tools have no support for writing
books collaboratively. Through this project, we have tried to explore the challenges in developing a tool
for fiction authors who want to write individually and collaboratively.
Signature of student:
Name:
Date:
Aahana Tomar,
Vaidik Kapoor
Signature of Supervisor:
Name:
Date:
Prof. Sanjay Goel
7
LIST OF FIGURES
Figure Page No.
Use Case Diagram 39
Class Diagram 40
Inter-relationship Graph 42
Integration Graph 45
8
LIST OF TABLES
Table Page No.
Functional Requirements 33
Non-functional Requirements 34
Logical Database Requirements 35
Risk Analysis 41
Risk Mitigation 43
Testing Plan 47
Component decomposition and type of testing required 49
Test Cases 50
Error and Exception Handling 54
9
LIST OF SYMBOLS & ACRONYMS
HCI Human Computer Interaction
CSCW Computer Supported Collaborative Word
HTML5 Hyper Text Markup Language v5
CSS Cascading Style Sheets
JS Javascript
WebRTC Web Real-Time Communication
UX User Experience
UI User Interface
DOM Document Object Model
API Application Programming Interface
WYSIWYG What You See Is What You Get
AJAX Asynchronous Javascript And XML
DOS Denial of Service
JSON Javascript Object Notation
10
CHAPTER 1 – Introduction
1.1 General Introduction
The need to develop tools for collaboration in different spheres of human activities with humans
not co-located was felt long back in the early 1980s. Since then, a very focused group of
researchers have been working towards understanding the human needs in the context of using
computers for supporting human activities and collaboration. [1] The field that deals with this
kind of study is called Computer Supported Co-operative Work. CSCW is a generic term, which
combines the understanding of the way people work in groups with the enabling technologies of
computer networking, and associated hardware, software, services and techniques. [2] Since
then, numerous tools for collaboration in organizations, document writing, office automation,
project management, etc. have been developed and deployed and notable success has been
achieved as well.
Even though developers and researchers have tried to cover different human activities, creative
writing specifically is an activity that has not been looked into very closely. A lot of work has
been done towards developing efficient synchronous editors for real-time collaboration, however
these editors mainly aid document creation in real-time and don't support the cognitive processes
in anyway that lead to creation of those documents.
Our intention is to simplify the activity of collaborative writing where not just document
preparation is the activity in focus but the activity of planning/ideation along with document
preparation collectively is considered one and important.
1.2 Problem Statement
As a part of this project, our aim is to identify the needs of authors who write fiction articles and
stories and develop an efficient tool to aid this activity. We have specifically chosen fiction
authors to be our audience because fiction writing is a truly abstract process and cannot be easily
structured. Authors decide their own working methodologies and processes. They cannot be
limited to a strictly structured environment.
Initially our objective was to develop an application that would aid collaborative writing a work
11
of fiction by two geographically distant authors. Upon exaggerated research and analysis it has
been concluded that it is imperative that we first construct an application for a single author to
personally plan and write a book and use this as a platform to support collaboration. Hence for
this stage alone, collaboration has been kept as a long term objective.
Currently, we have to understand the processes involved when a single author is structuring a
piece of fiction. Upon understanding we need to identify the problems occurring in a real world
scenario and create an application that yields solutions to those problems. This will help the
author to plan and write with ease and efficiency.
Great amount of research and understanding is involved to gain insight into the cognitive aspects
of writing. The support tools should render to every need of the author and the application has to
be intelligent enough to steer the author in the right direction without thrusting an iron clad
structure on him.
1.3 Empirical Study
1.3.1 Collaborative Writing Activity in the Same Space:
We conducted an activity where two people had to collaborate on an article (fiction) in the
same space (i.e. the same room at the same time). The objective of the activity was to
observe the whole activity of writing a fiction story as to how the participants behave in
the activity, what do they talk about, what do they discuss, how do they discuss ideas,
what difficulties do they face, what tools and resources do they require, etc. The outcome
of these observations helped us understand the needs of authors in general and further
helped us understand how can we develop an environment where authors can collaborate
without being in the space.
Learning Outcome:
• All the collaborators should have a similar mindset and the way they think.
• All the collaborators should have a similar writing style.
• They generally plan before they start writing. This plan will not always be externally
12
represented. From person to person, this differs.
• The cognitive process of doing a creative activity is one of the most important things
that the active participants in the activity do. In this activity, this happened with the
help of:
◦ Discussions.
◦ Use of paper and pen to explain ideas through drawings to each other.
◦ Use of the internet to do research.
• Sometimes in a collaborative activity like such, a collaborator is so involved in his
own thinking that he/she sometimes forgets to listen to what the other person is
saying.
• Resolution of conflicts is a difficult process. In case of different spaces, it can be
even more difficult.
• They needed resources to refer to quickly at the time of writing – internet, thesaurus,
dictionary, etc.
1.3.2 1st Validation
Book Name: The Lady, Or The Tiger?
Author: Frank R. Stockton
This, extensively anthologized short story was published in The Century Magazine in
1882. It is set in the 6th
Century A.D. In this exercise, our goal is to envisage Stockton’s
process of planning and writing this short story, try to trace it to our Application and to
further identify the glitches in it. The story stands firmly on two pillars- the historical
pretext and a deep understanding of the human psyche, with the latter having had no need
to be researched.
Learning Outcome:
While doing this activity, few shortcomings of the Application came to light. The hairline
difference between event and scene became clearer after conducting this activity. An event
is a fact; it is either the background or the foreground of a scene. Scenes and events are
13
parallel to each other with the latter following a chronological order. Events provide a
reason or understanding to a scene. Scenes have an agenda, they have a conflict but events
are pure facts. With reference to the story discussed:
Events:
• The Semi-barbaric king enjoys deploying his wild fancies to a few matters to public
affairs. He has therefore established a unique method to judge the innocence or guilt
of the deliquescent of his kingdom, wherein they are left to a chance of fate and
punished or rewarded immediately. This florid ritual has become a source of
entertainment to both the king and his pupils.
• The king’s daughter falls in love with a royal subject, who is immediately
imprisoned.
• He too has to face the trial now.
• The princess, true to her nature, somehow retrieves the truth of what lies behind each
door.
• But she is tormented because she cannot decide if she could see her lover be wedded
to another woman and let this truth scathe her for the rest of her life. She is faced
with a question that does not seem to have any answer.
• On the day of the trial she manages to convey to him which door to open
• The author does not reveal the choice made by the princess, instead leaves it on the
reader to judge. Who came out of the door, The Lady or the Tiger?
Scenes:
There is only one scene in the story: The day of the trial where in the subjects looks at
nobody but the princess in the look of the eye asked her the question and with the gesture
of a hand she too returned the answer. He promptly followed her and opened the door.
Conclusion:
As a result of this exercise, we understood that Events as a dedicated building block is
necessary for planning purposes. Therefore, Events and Scenes will have the following
fields:
14
Scene: Characters, Location, Backdrop, Agenda, Conflict, Action, Dialogues
Event: Characters, Location, Dialogues, Backdrop, Conflict
1.3.3 2nd Validation
Book Name: Veronica Decides to Die
Author: Paulo Coelho
Veronika Decides to Die is a novel by Paulo Coelho. It tells the story of 24-year-old
Slovenian Veronika, who appears to have everything in life going for her, but who decides
to kill herself.
Learning Outcome
The Application so far, has been structured for a short story and even though it will cater a
novel on the superficial level, problems crop up when one starts to dig in deeper. For
instance, one can plan out each character, the setting, the theme extensively, using this
Application. Problems will occur in planning out the Plot. There will be a plot to the entire
story but here will be sub plots in every chapter too. There will be scenes and events that
will have to be strung carefully. The events of the novel will follow a chronology
irrespective of the chapter and the point of view from which the novel is written. The
scenes and subplots would be developed using these events as foundation.
This book has been written from the point of view of a third person and has a linear
approach. Chapter-wise planning needs to be given more thought.
1.4 Solution Approach
So far, we have been working towards understanding fiction writing, the issues associated with
fiction writing in single-user environments and the requirements for developing a multi-user
environment for the same. In the process, we have conducted activities and deeply analyzed
15
existing single-user tools to get a deeper knowledge of the processes involved in writing fiction.
However, analysis for developing a multi-user environments is quite different as compared to
analysis for development of single-user environments because in the latter, only a single user is
involved but when more than one user is involved, the evaluation procedure gets more based on
the methodologies of social psychology and anthropology. A single-user application may get
away with appealing to a kind of “lowest common denominator”. CSCW applications will often
have to appeal to every possible denominator. [3]
To tackle the problems with multi-user environments as stated above along with developing an
effective tool for authors who want to write fiction is a complex process. Furthermore, we will
not be able to propose an effective solution unless we solve the more fundamental problem of not
having a good authoring tool for single authors only.
Therefore, we have decided to first develop a single-user fiction authoring tool that will support
the fundamental processes of writing fiction out-of-the-box. This will be the main objective of
our project for this semester. After developing and successfully validating this tool to an
acceptable extent (i.e. by validating the tool by a couple of actual authors), we will work towards
adding real-time features for enabling this application to be used by more than one authors.
These objectives shall be achieved while working on our project in the next semester.
We understand that fiction writing is a creative process and cannot be discretely structured or
designed because every author has her own style and processes of writing a story. Therefore, we
have continuously kept ourselves involved with trying to learn more and more about the
structured studies about fiction writing available publicly. In addition to this, we have conducted
several activities to understand the whole process better and have been working towards
developing a model for this tool.
Earlier, we had divided our project in four main discrete phases, according to which we have
already completed Phase 1 and are in the middle of Phase 2. However after doing more studies
about our project, we have come to understand that there are going to be recurring activities.
Therefore, we have revised our phases as follows:
16
• Phase 2
◦ On the basis of the analysis done so far, prepare a conceptual model for the
application.
◦ Dry-run the mock-ups through the process of re-engineering existing short stories.
Iterate until an acceptable conceptual model is achieved.
◦ Start working on a basic functional prototype for desktops only, but with design
decisions made for mobile devices as well.
• Phase 3
◦ Start developing the prototype of the mock-up decided in Phase 2 for desktop and
mobile devices (to follow the “Mobile First” theory).
◦ Validate the prototype with volunteers. Study the issues faced by actual users and
iterate until satisfied.
• Phase 4
◦ Start working towards taking the prototype to the stage of a fully functional tool by
integrating with the back-end.
◦ Start validating the tool with real audience.
◦ Iterate to improve features, performance and usability.
1.5 Approach to problem in terms of technology and platform to be used
Platform: Our preference of platform is the Web. The Web is the new platform. With minimal
effort, it will enable us to reach a larger audience by enabling us to easily bring the tool to
desktops and mobiles at the same time. Mobile is an important platform today and cannot be
ignored. A considerable percentage of the third world countries' population's first hand
experience of operating a computer happens through mobile devices. The Web is continuously
evolving with a fast pace and it is attracting a lot of attention. With this continuous evolution,
we will get enough resources to develop this tool and improve it with time as newer
technologies are introduced.
Web Real-Time Communication: WebRTC is an API definition being drafted by the World
17
Wide Web Consortium (W3C) and jointly in the IETF with a chartered working group.[4] The
goal of WebRTC is to enable applications such as voice calling, video chat and P2P file sharing
without plugins. WebRTC is what our tool will base on to implement VoIP like features for
communication between authors.
WebSocket: WebSocket is a web technology providing for bi-directional, full-duplex
communications channels over a single TCP connection. The WebSocket API is being
standardized by the W3C, and the WebSocket protocol has been standardized by the IETF as
RFC 6455. [5] WebSockets will form the base for the implementation of Operational
Transformation, a set of algorithms developed by Google for their Google Wave project. [6]
HTML5: HTML5 contains powerful capabilities for Web-based applications with more
powerful interaction, video support, graphics, more styling effects, and a full set of APIs. [7]
Cascading Style Sheets: CSS3 is a simple mechanism for adding style (e.g., fonts, colors,
spacing) to Web documents. [8]
JavaScript: is a prototype-based scripting language that is dynamic, weakly typed and has first-
class functions. It is a multi-paradigm language, supporting object-oriented, imperative, and
functional [9][10] programming styles.
NodeJS: Node.js is a platform built on Chrome's JavaScript runtime for easily building fast,
scalable network applications. Node.js uses an event-driven, non-blocking I/O model that
makes it lightweight and efficient, perfect for data-intensive real-time applications that run
across distributed devices. [2]
Meteor: Meteor is a platform built on top of NodeJS to allow development of modern web
applications with real-time capabilities, hot code pushes, etc. [11] MeteorJS is makes use of
NodeJS and Comet and a lot of other existing libraries.
18
1.6 Support for Novelty
Technology finds its application in every field and it has brought convenience to every aspect of
our lives. Its unique feature of continuous evolution and simplicity in complexity makes it
indispensable. Several software have been developed which help amateur writers compose
works of fiction. Unfortunately these software have not been able to create a niche for
themselves in the authors community and fiction authors to be precise.
Enhancing the usability of the existing software and helping authors to collaborate a fiction
novel makes this project novel. The significance of this problem resides in the bare fact that
there is a meager number of Computer Supported Multiple-Author books. Geographically distant
yet eager to write authors form the audience of this project.
The tool developed, will not be a stringently structured environment which kills creativity.
Objectives like: user friendly interface, effective tools, skillfully segregated work spaces, real
time editor, audio-video aided chat application, support for mobile devices and tablets will help
the authors to contribute to their novel rather than getting entangled in unnecessary confusion.
19
CHAPTER 2 – Literature Survey
2.1 List of all the sources for formulation of problem statement
Papers:
1. Responsive Web Design
2. Responsive Web Design: What It Is and How To Use It
3. Mozilla UX Research: Save for Later
4. Awareness Displays and Social Motivation for Coordinating Communication
5. Issues in the Design of Computer Support for and Commenting
6. Awareness and Coordination in Shared Workspaces
7. Computer Supported Co-operative Work: History and Focus
8. Why CSCW applications fail: problems in the design and evaluation of organization of
organizational interfaces
Books:
1. Aristotle's Poetics
Existing Tools:
1. MediaWiki
2. EtherPad
3. Google Wave
4. Drammatica
5. StoryBook
6. LitLift.com
7. Celtx.com
8. My Writing Spot
9. Pressbooks
10. Protagonize
11. Scrivener
12. Mendeley (not a writing tool but source of inspiration)
13. Writer's Cafe
20
2.2 Summary of Relevant Papers
Title Responsive Web Design
Authors Ethan Marcotte
Year of Publication 2010
Publishing Details A List Apart
Web Link http://www.alistapart.com/articles/responsive-web-design/
Summary The article introduces the concept of Responsive Web Design and how it
is required today to design web applications that can effectively run on all
kinds of devices. Today, we need to build applications for all the
platforms out there. Building applications for all the platforms is possible
however the heterogeneity of platforms makes it extremely difficult to
make the same application for different platforms. This article talks about
making use of the power of HTML5 & CSS3 to build responsive web
applications using Media Queries that change the size, organization and
appearance of their layouts and essential UI elements.
The article further gives examples of how Media Queries can be used to
ask the browser to interpret specific CSS files on the basis of width of the
device and width the of the browser's viewport. Finally, the article
introduces the concept of Grid based layouts for designing responsive
web applications.
Title Responsive Web Design: What It Is and How To Use It
Authors Kayla Knight
Year of Publication 2011
Publishing Details Smashing Magazine
21
Web Link http://coding.smashingmagazine.com/2011/01/12/guidelines-for-
responsive-web-design/
Summary The author discusses that limiting your web application to only desktop
hurts the audience you can reach and serve. There is a need of building
responsive web applications to allow your application to penetrate better
within your target audience by supporting various devices with various
screen sizes.
The author discusses how making everything flexible from the ground-up
can be a right way of solving the multi-device-single-code-base problem.
However, images break layouts until HTML5 was introduced. Now, even
images can be flexibly resized and sliced.
The author further talks about how and what screen sizes should be taken
care of on the basis of importance of audience, importance of platform
and other parameters. The author also discusses how to handle complex
elements like images, navigation, articles, etc. Different mobile device
also pose an orientation problem which can not be solved with the help of
CSS3 Media Queries. The author also highlights the importance of what
to hide elements on mobile devices and show only the necessary elements
because of lack of space.
Title Mozilla UX Research: Save for Later
Authors Brian Groudan
22
Year of Publication 2012
Publishing Details Mozilla User Experience Blog
Web Link https://blog.mozilla.org/ux/2012/10/save-for-later/
Summary The Firefox for Android team wanted to know why bookmarks usage was
minimal on mobile devices and if users would be more likely to
bookmark if the feature was designed differently. Therefore, the User
Experience (UX) team at Mozilla conducted a study to identify the issues.
The UX team at Mozilla began their study by first trying to identify what
are bookmarks used for by the people and what purpose do bookmarks
solve for the end-user. They conducted a study of how users use
bookmarks in their day-to-day life by asking the participants of the study
to record their actions by themselves. As a result of this study, the
research team identified various purposes for which bookmarks in Firefox
is used. They also identified other services which are used instead of
Firefox's bookmarks for the same purposes. They also analyzed user
behavior data on the basis of data collected by Test Pilot to understand
how quantitatively Firefox's bookmark feature is used by a user everyday.
On the basis of the results of these studies, the team of researchers
identified the requirements and the design goals of re-engineering
bookmarks in Firefox to make bookmarking and saving links for later use
easy, intuitive, highly available, centralized. The project's code name is
Dropzilla.
This report helped us understand how to understand the needs of our
target audience i.e. authors and how to conduct the study and how to
proceed further to draw conclusions and design tools for our own project.
Title The concept of activity as a basic unit of analysis for CSCW
23
research
Authors Kari Kuuti
Year of Publication 1991
Publishing Details Proceedings of the Second European Conference on Computer-Supported
Cooperative Work
Web Link http://dl.acm.org/citation.cfm?id=1241929
Summary This paper introduces Activity Theory as the basic unit of analysis for
understanding activities important for application of CSCW.
The basic idea is that there exists a "fundamental type" of context, which
is called an activity. It is meaningless to study essentially human qualities
using a smaller object of research, because without that basic context one
cannot grasp the essence of the phenomenon.
The activities in which humans participate are the basic units of
development and human life, and thus form a foundation of the study of
all contextuality. Activities - an individual can participate in several at the
same time - have the following properties:
• an activity has a material object and activities can be distinguished
according to their objects. The transformation of the object
towards some desired state or in some direction motivates the
existence of an activity.
• an activity is a collective phenomenon.
• an activity has an active subject, who understands the motive of
the activity. This subject can be individual or collective. Not all
24
participants involved in an activity necessarily understand the
motive of the activity in which they are participating or even
recognize the existence of it. In this case they are not active
subjects of the activity.
• an activity exists in a material environment and transforms it.
• an activity is a historically developing phenomenon.
• contradictions are the force behind the development of an activity.
• an activity is realized through conscious and purposeful actions by
participants.
• the relationships within an activity are culturally mediated.
It is suggested here that Activity Theory offers a promising framework for
CSCW research, because the concept of the activity as the basic unit of
work analysis seems to meet a number of acute demands expressed by
CSCW researchers.
Title Aristotle's Poetics
Authors Aristotle, Gerald F. Else (Translator)
Year of Publication 1957
Publishing Details University of Michigan Press
Web Link http://www.flipkart.com/aristotle-s-poetics-
0472061666/p/itmczzaagpuzubgg
Summary The project, Collaborative Fiction Authoring rests on two interdependent
tires, namely, collaboration and authoring. One has to study the
fundamental requirements and rules of both collaboration and authoring
at depth, and create a tool that effectively and effortlessly facilitates two
or more authors to compose a piece of work together.
25
Aristotle’s Poetics is a dependable and comprehensive resource which
explores and objectively lays down the rules for writing a piece of fiction.
An extensively dissected study of the same will help us understand the
entire process of writing and henceforth develop a more efficient tool.
Following is the learning outcome:
• The centre stones of the book are:
◦ Every work of fiction is an imitation of men in their action.
◦ The plot should be continuous and all the elements should tie
down at climax.
◦ Catharsis or, outburst of emotions like fear, pity etc. should be
the outcome of the story.
• Narrative (the author enforces his opinion on the reader eg:
novels) and Dramatic (the reader is free to form his own opinion
about the characters and events, eg: plays) are the two forms of
writing and our tool should be able to render help to create both.
• Work of fiction is divided into 6 parts:
◦ Plot - chronological events of the story.
◦ Characters - the actors who carry the story.
◦ Thought - theme of the story.
◦ Diction- style of delivering dialogues in case of plays.
◦ Melody - mood of the play.
◦ Spectacle - the set up in case of a play and the surroundings in
case of a story.
• Plot:
◦ It must be complete with a beginning, middle and end.
◦ Complex plots are of the best kind which arouse emotions like
pity, fear etc.
• Procedure for plot construction:
26
◦ Author should visualize the actions of the story as vividly as
possible.
◦ Should even try acting out the events as he writes them.
◦ Routine the over-all plot of the story and then flesh out the
episodes.
◦ Author should write about focused incidents.
• Characters
◦ Should be complex and interesting who arouse curiosity.
◦ Appropriate portrayal.
◦ Life - like and true to their nature
◦ Consistent. Even the inconsistency should be consistent.
• Should consist of complication and denouement.
Aristotle's method raises the question of whether fiction authoring can be
studied in the same way as the natural sciences. Though there are some
benefits to Aristotle's method, the ultimate answer seems to be "no". Art
often thrives and progresses by questioning the assumptions or laws that a
previous generation has accepted.
Title Issues in the Design of Computer Support for Co-authoring and
Commenting
Authors Christine M. Neuwith, David S. Kraufer, Ravinder Chandhok, James H.
Morris
Year of Publication 1990
Publishing Details Proceedings of the Conference on Computer-Supported Cooperative
Work 1990
Web Link http://dl.acm.org/citation.cfm?id=99354
Summary There are two important aspects to collaboration as highlighted by this
paper: social an cognitive.
27
The social aspect of collaboration involves the process of co-ordination to
a great extent. We have to consider the activities the writers have to
perform by the virtue of which they have to work together rather that
alone. Of these, support for definition of social roles and support for
communication plans are important in the context of our project.
Cognitive aspects of an activity are decided more specifically by the kind
of activity taking place. They also depend on the active participants of the
activity. Some task specific activities involve drawing, jotting, sketching,
writing, etc. When writers (experienced or inexperienced) work in
environments that do not have support for these activities, they report
frustration as these activities are essential tools for them. Many of the
writers resort to paper to produce intermediate representations, such as
plans for drafts, trees depicting structural characteristics of an outline or
draft, etc. These writers often want to create these as quickly as possible
and they often treat these only as temporary sketches, doodles, etc.
Title Awareness and Coordination in Shared Workspaces
Authors Paul Dourish, Victoria Bellotti
Year of Publication 1992
Publishing Details Proceedings of the Conference on Computer-Supported Cooperative
Work 1992
Web Link http://dl.acm.org/citation.cfm?id=143468
Summary This paper highlights the importance of awareness in shared workspaces.
Awareness is an understanding of the activities of others, which provides
a context for your own activity. The authors emphasize that awareness
information is always required to coordinate group activities, whatever
the task domain. Although we deal largely here with collaborative text
editing, other collaborative activities can benefit equally from the
approach we outline.
28
The awareness problem has been dealt with for so many years but all the
existing ways have time and again proved that the user who provides the
information does not directly benefit.
A widely used mechanism, referred to as Informational, is to provide
explicit facilities through which collaborators inform each other of their
activities. For instance, wiki such as MediaWiki ask users to provide text
for an “edit log” which describes the nature of changes. In this case, it is
clearly visible that the writer has to enter the “edit log” for the benefit of
others and not for self.
A second mechanism, which we refer to as role restrictive, arises from
explicit support for roles in collaborative systems. A role describes an
individual's relationships to the shared work objects and to other
participants, and is typically linked to a set of operations which can be
performed. In a shared authoring system, for instance, an “author” role
might be associated with the read, write, create, delete and edit
operations, while a “reviewer” might be limited to read and annotate.
Though this mechanism is capable of keeping track of actions performed
per user but there is a significant trade-off with respect to benefits. The
price of heightened awareness for the group is clearly restriction in the
potential activities of individuals.
All of these systems clearly embody an assumption that a simple
awareness of others' activity needs to be augmented with other explicit, or
restrictive mechanisms for ensuring an easy collaboration, such as
annotations, role assignment, access rights and so forth.
29
Title Why CSCW applications fail: problems in the design and
evaluation of organization of organizational interfaces
Authors J. Grudin
Year of Publication 1988
Publishing Details Proceedings of the Conference on Computer-Supported Cooperative
Work 1988
Web Link http://dl.acm.org/citation.cfm?
id=62266.62273&coll=DL&dl=GUIDE&CFID=150339148&CFTOKEN
=95744269
Summary Many systems, applications, and features that support cooperative work
share two characteristics: a significant investment has been made in their
development, and their successes have consistently fallen far short of
expectations.
The important points that the paper highlights about failure of CSCW
applications are:
• The application fails because it requires that some people do
additional work, while those people are not the ones who perceive
a direct benefit from the use of the application.
• The design process fails because our intuitions are poor for multi-
user applications -- decision-makers see the potential benefits for
people similar to themselves, but don’t see the implications of the
fact that extra work will be required of others.
• We fail to learn from experience because these complex
applications introduce almost insurmountable obstacles to
meaningful, generalizable analysis and evaluation.
• The best solution is to try to insure that everyone benefits directly
from using the application. This may mean building in additional
features. It certainly means eliminating or’ minimizing the extra
work required of anyone, or rewarding them for doing it.
• The experience, and very likely the track record, of a development
30
manager considering a CSCW application is generally based on
single-user applications. Intuition may be a far more reliable.
guide to single-user applications -- a manager with good intuition
may quickly get a feel for the user’s experience with a word
processor, spreadsheet, or so forth. But a typical CSCW
application will be used by a range of user types -- people with
different backgrounds and job descriptions, all of whom may have
to participate in one way or another for the application to succeed.
• Evaluation of CSCW applications requires a very different
approach, based on the methodologies of social psychology and
anthropology.
It concludes that investing resources adequate to the solution of the
problems, developing the appropriate research and development
methodologies, finding niches where the problems don't arise or where
applications will succeed in spite of them, and adequately preparing users
for the introduction of the applications are all approaches that may lead to
success.
CSCW applications will have to be more “group-friendly” than systems
have been. They will change the organization, but more gradually. For
this reason. the focus of CSCW will shift to user interface issues to
minimize the disruption and additional work required of any user of the
application.
31
CHAPTER 3 – Analysis, Design and Modeling
3.1 Overall description of the project
We have identified that the tool will be broadly divided into two parts:
• Planner – the part that will be used by the user to ideate and plan the book.
• Editor – to write and manage the book.
The above two parts are broadly identify what a user will be doing i.e. first plan/ideate the book
and then write. According to the study and analysis we have done so far, we have identified
certain features for the above two parts/modules.
Writing fiction is a creative process and every author has her own style, processes and methods.
To come up with one tool for the same is non-trivial. Therefore, we have decided that our efforts
must be in the direction of understanding the process of fiction writing and then trying to make a
tool that is very flexible.
Both the modules of the tool will have a dedicated screen for themselves such that the visible
screen will have features and functionality of that module.
Planner: The planner will allow the user to ideate, brainstorm and plan their book. Planning a
book is a complex process and no single author does that in the same way. So many tools have
been developed to help authors write. However, their adoption have failed because of the
complexity involved. We are trying to make the planning process extremely simple for authors
by trying to dampen the learning curve. Planning a book is an abstract process and one might
approach it from any angle. This part
Editor: The editor will be more of a document editor, though with some new features and most
of the features of existing document editors missing because they are not required. This will
allow the author to concentrate more on writing and the new features will promise to help the
author write.
Global Features: This is not a separate important module but a collection of help tools like
32
Dictionary & Thesaurus. There will be some features we have identified that will be common to
both the planner and the editor. These tools will be of general purpose that can be used both with
the planner and the editor.
3.2 Functional Requirements
Dictionary & Thesaurus • User input of word or phrase
• Dictionary API
• In-browser Context Menu
References • Files
• Links Verification
• URL Meta Data Parser
• Notes
• Media
• Device Camera
• Device Microphone
• Video & Audio Conversion
Story Planner • User Content
• References
• Drag and Drop
• Drag-able & Zoom-able Workspace
• Modal Windows
• Timeline Slider & Organizer
Editor • WYSIWYG Editor
• Table of Contents Organizer
Global Requirements • Diff Generator
• Version Generator
• Client-Side Change Detection
• Auto Save
33
3.3 Non-Functional Requirements
The tool shall be intuitive and easy-to-use. • Consistent in design.
• Usable.
• Ergonomic.
The tool shall be flexible for users to use it the way
they want and must not impose restrictions.
The tool shall be extensible enough to add new
features and functionality.
The tool shall store the user's data reliably. • Auto-save feature must detect
changes and save the data at regular
intervals of 5 seconds if changes
are made.
• If internet connection is not
available, the tool must store the
changes in the browser's
LocalStorage database. [12]
The tool shall be highly available. • Robust servers
• Systems should be as safe as
possible from DOS/DDOS attacks.
• Low down-times.
The tool shall be responsive so that the user does
not have to wait long for actions to complete.
• Extensive use of AJAX to avoid
large responses from the server.
• All responses must reach the client
within 2 seconds (not in-case of
networks with extremely low
latency).
The tool shall be secure. • HTTPS
• Secure and slow password hashing
• Secure storage systems (encryption
must be employed).
The tool shall save versions of project data. • Previous versions up to a certain
number of days depending on
storage constraints.
The tool shall make fast API calls for dictionary • For all practical purposes, response
34
and thesaurus. to API calls should be served within
2 seconds.
3.4 Logical Database Requirements
3.4.1 Database Design
Table Name Columns and their types Comments
users • user_id (int, primary key)
• email (varchar)
• name (var_char)
• image (longtext)
• registration_date (timestamp)
• password (varchar)
• last_login (timestamp)
• For storing user
data.
reference_types • reference_type_id (int, primary key)
• reference_type (varchar)
• For storing types of
references. Ex:
audio, image, link,
etc.
• Mostly static unless
we choose to
support new kinds
of references.
references • reference_id (int, primary key)
• project_id (int, foreign key
[projects.project_id])
• title (varchar)
• reference_type_id (int, foreign key
[reference_types.reference_type_id])
• value (longtext)
• length (int)
• size (int)
• For storing
references.
35
• notes (longtext)
• timestamp (timestamp)
tags • tag_id (int, primary key)
• project_id (int, foreign key
[projects.project_id])
• tag (varchar)
• timestamp (timestamp)
• For storing unique
tags.
reference_tags • reference_id (int, foreign key
[references.reference_id])
• tag_id (int, foreign key [tags.tag_id])
• timestamp (timestamp)
• For storing
relationships
between tags and
references.
projects • project_id (int, primary key
[projects.project_id])
• user_id (int, foreign key
[users.user_id])
• project_name (varchar)
• timestamp (timestamp)
• For storing project
information.
object_types • object_type_id (int, primary key)
• object_type_slug (varchar)
• object_type_name (varchar)
• For storing object
types (or tools).
• Mostly static unless
we choose to add
new tools.
objects • object_id (int, primary key)
• object_type_id (int, foreign key
[object_types.object_type_id])
• project_id (int, foreign key
[projects.project_id])
• title (varchar)
• structured_content (JSON)
• notes (longtext)
• For storing objects
created using tools.
36
• order (int)
object_relationshi
ps
• object_1_id (int, foreign key
[objects.object_id])
• object_2_id (int, foreign key
[objects.object_id])
• notes (longtext)
• For storing
relationships
between different
objects.
object_references • object_id (int, foreign key
[objects.object_id])
• reference_id (int, foreign key
[references.reference_id)
• timestamp (timestamp)
• For storing
relationships
between objects and
existing references.
chapter_documen
ts
• chapter_id (int, primary key)
• project_id (int, foreign key
[projects.project_id])
• chapter_name (varchar)
• content (longtext)
• chapter_order (int)
• part_id (int, foreign key [parts.part_id])
• timestamp (timestamp)
• For storing chapters
created using the
editor and which
part do they belong
to.
parts • project_id (int, foreign key
[projects.project_id])
• part_id (int, primary key)
• part_name (varchar)
• part_order (int)
• timestamp (timestamp)
• For storing
information of
parts.
history • history_id (int, primary key)
• table_name (varchar)
• primary_key (int)
• timestamp (timestamp)
• reverse_patch (longtext)
• For storing versions
of all types of data
that needs to be
versioned.
37
3.4.2 Frequency of Use
• Maximum average of 1 write / 5 seconds / live-user (safe to assume because the auto-
save feature will attempt to save every 5 seconds only if the user has changed any data
on the client-side).
• Assuming a minimum average of database reads at this stage is not possible. This can
only be approximated by examining user behavior.
3.4.3 Accessing Capabilities
• JSON data type.
• Fast I/O for fast AJAX calls.
3.4.4 Data Entities and their Relationships
• users have 1-to-many relationship with projects.
• projects have 1-to-many relationship with references.
• references have many-to-many relationship reference_tags.
• projects have 1-to-many relationship with objects.
• references have many-to-many relationship with objects.
• projects have 1-to-many relationship with parts.
• parts have 1-to-many relationship with chapters.
• objects have many-to-many relationship with themselves.
3.4.5 Data Retention Constraints
Users will use this tool for their work, meaning they will be saving their lives work and research.
It is essential for this tool to handle their data reliably and make sure that the their data remains
safe.
38
The tool must:
• Retain all the project data until and unless the user chooses to delete it.
• Retain N latest older versions of various components of the project. The value of N will
depend on the constraints of the systems used in projection.
3.5 Design Diagrams
3.5.1 Use Case Diagram
Actors:
• Author
39
3.5.2 Class Diagram
40
3.6 Risk Analysis
Risk Id Classification
(Acc to SEI
taxonomy)
Description of
Risk
Risk Area Probability Impact RE
(P* I)
1 Personnel
Management
(Development
Environment)
Irregularity →
schedule will be
affected
Personnel
Related
H (5) H (5) 25
2 Deliverability
(Development
Environment)
Excessive
evolution of
problem statement
→ delay in
project
deliverable
Project
Scope
H (5) H (5) 25
3 Usability
(Development
Environment)
Constrain on data
models → risk of
limiting user
friendliness
Performance M (3) H (5) 15
4 Capacity
(Development
Environment)
Wide scope of
functionality of
project →
unrealistic
expectations from
the project
Project
Scope
L (1) H (5) 5
5 Personnel
Management
(Development
Environment)
One partner on
long vacation →
that part of work
was not available
Personnel
Related
L (1) H (5) 5
41
6 Interfaces
(Product
Engineering)
Random input
from user →
desired outcome is
not achieved.
External
Inputs
L (1) H (5) 5
7 Usability
(Development
Environment)
Complex input
format →
reduced/erroneous
input provided
External
Inputs
L (1) M (3) 3
S.No. Risk Area No. of Risk
Statements
Weights (In
+ Out)
Total Weight Priority
1 Performance 4 9 + 9 + 3 21 1
2 Personnel
Related
2 3 + 9 12 2
42
3 External
Inputs
2 3 + 9 12 3
4 Project Scope 1 3 + 3 6 4
Risk Statement Risk Area Priority of Risk
Area in IG
Constraint on accuracy → risk of limiting user
friendliness
Performance 1
Wide scope of functionality of project →
unrealistic expectations from the project
Project Scope 4
Excessive evolution of problem statement → delay in
project deliverable
Project Scope 4
One partner on long vacation → that part of work was
not available.
Personnel Related 2
Irregularity → schedule will be affected Personnel Related 2
No input from user → project execution
Freezes
External Inputs 3
Complex input format → reduced/erroneous
input provided
External Inputs 3
3.7 Risk Mitigation
Risk Mitigation
Approaches
Date Started Date to
Complete
Owner Additional
Resources
needed for
Mitigation
Irregularity →
schedule will
be affected
Conduct
weekly review
meeting with
mentor and
other students
working under
28 – 01 - 13 26 – 04 – 13 Mentor Presence of
other groups
under our
mentor during
meetings.
43
same mentor.
Excessive
evolution of
problem
statement →
delay in project
deliverable
Settle at a point
and begin
implementation
to ensure
completion.
02 – 02 – 13 20 – 04 - 13 Mentor None
Constraint on
data models →
risk of limiting
user
friendliness.
Repeatedly
validate project
model with
real-world
applications
and real users.
01 – 04 - 13 27 – 05 - 13 Aahana, Vaidik None
44
CHAPTER 4 – Implementation and Testing
4.1 Implementation details and issues
4.1.1 Implementation
4.1.1.1 Modeling
For allowing the author to approach her story with ease without getting imposed by any
structure we have designed for this application, we have approached the design of our
application in such a way that the author may choose to do whatever she wants at any
given time.
The above approach allows the author to begin working on a project from any direction
i.e. the author may choose to:
45
• start by planning and then go on to write.
• start by writing and plan while she writes.
• start by collecting notes and references and uses the tool for only that purpose
along with writing.
There can be many such combination of approaches and the user may choose whichever
she is the most comfortable with.
4.1.1.2 Prototyping
On the basis of the above design, we designed some functional fidelity paper prototypes
for our application, reviewed it and revised it for improving it according to our
understanding. The prototypes are available in Appendix #.
4.1.1.3 Validation
We validated our prototypes and application's model by rewriting an existing story with
our tools prototypes. In this process, we identified numerous issues with our prototypes
and learned new things about the fiction writing process. The activity's report is
available in Appendix #.
4.1.1.4 Implementation
With the results of our validation process, we started working on a medium fidelity
interactive prototype of the planning section. This prototype will also be used in getting
our application's model validated by actual users.
4.1.1.5 Issues
• Existing model needs more thorough validation to freeze the fundamental tools
needed for story planning.
• Application stores data only in the browser's LocalStorage and IndexedDB stores.
• Actual authors are required for thorough validation and insights in the process of
writing. Unfortunately, we haven't been able to get in touch authors.
• Development for mobile devices is essential but at the same time it is more work and
46
complex as well. Even though we have taken the easier route of developing a
responsive application, it is still complex and time consuming.
4.1.2 Debugging
Our application gets data from users actions and behavior inside the browser. Furthermore, we
use HTML5 specification's LocalStorage and IndexedDB to store our data inside the browser
first to handle latency and data loss issues. For debugging. we have extensively used the
following tools:
• Chrome Dev Tools
• Chrome Javascript Debugger
• Javascript's console.log() function for variable inspection at different steps.
4.1.3 Error and Exception Handling
There are many areas of our application that have required us to handle generic exceptions fired
by Javascript. Those cases are as follows:
1. Internet is not available: appropriate messages are shown when features that require the
Internet are used.
2. Dictionary & Thesaurus service is down: application looks for words in a cache with an
appropriate message saying that the service is temporarily down and we are showing
cached results.
3. Link added in Data Collection is invalid: the user is warned for the same.
4. LocalStorage does not exist: restarts the application from the very beginning and handles
situations where data is expected.
4.2 Testing and Evaluation
4.2.1 Testing Plan
Type of Test Will test be
performed?
Comments Software Component
Unit Testing Yes The application is mainly
divided into three main
• Planner
• Data Collection
47
components – editor, planner
and data collection. Apart from
this, a custom LocalStorage
ORM has been written for the
application.
Note-taking service REST API
server exists to receive HTTP
requests when the user interacts
with the mobile app.
The SMS server exists to
receive HTTP requests when a
particular number receives a
message from the author. This
message is further processed
and broadcasted to users.
• Editor
• DataStore ORM
• Dictionary &
Thesaurus
• Note-taking REST
API Server
• SMS Server
Integration
Testing
Yes Our application's modules are
inter dependent.
• Editor
• Planner
• DataStore ORM
• Dictionary &
Thesaurus
Performance
Testing
No At the current stage of
development, our aim is to
focus on development more
than performance.
Stress Testing No At this stage, we have not
identified stress points for this
application as feature
development is higher priority.
Compliance Yes Since our application is a web • Complete
48
Testing application, we have made sure
that our client-side code
complies with all W3C's
HTML5 specification. We have
verified this using the W3C
compliance validator.
Application
Security Testing No Feature development is higher
on priority. Furthermore, all
communications will happen
using the HTTPS (Secure)
protocol, which will eliminate
most of the security loop-holes.
Load Testing Yes LocalStorage affects
performance of the browser
depending upon the size of the
data it is holding.
• Planner
• Dictionary &
Thesaurus
• Data Collection
Testing Environment
Software Used Description
Operating System (Server):
Fedora 17
The application is hosted on an Nginx web server, running on
Fedora 17.
Operating System (Client):
Windows 7, Mac OS X and
Fedora 17
The application has been opened and tested manually in
different operating systems.
Browser: Google Chrome
20.0.18, Firefox 19 Nightly
The application has been opened and tested manually in a
few different browsers. The automated tests are run inside
the browsers. Tests are written in Javascript.
Web Server: Nginx, NodeJS
HTTP Static
The web server software that is used is NodeJS HTTP Static,
which sits behind Nginx that acts as a proxy.
4.2.2 Component decomposition and type of testing required
49
S. No. Components that require
testing
Type of testing required Technique for writing
test cases
1. Dictionary & Thesaurus Unit Testing Black Box
2. Building Block Unit Testing Black Box
3. Data Collection Items Unit Testing Black Box
4. DataStore (LocalStorage) Unit Testing Black Box
5. Editor Unit Testing Black Box
6. Complete Application Compliance Testing W3C's HTML5
specification validator
4.2.3 Test Cases
1. Dictionary & Thesaurus
Test Case
ID
Input Expected Output Status
1. Word: A dictionary word (like “play”) Response: Parseable JSON
Object
Status: 200
Pass
2. Word: A non-dictionary word Response: Parseable JSON
Object
Status: 404
Pass
3. Word: A dictionary word (like “play”) Response: Parseable JSON
Object
Status: 500
Fail
4. Word: A dictionary word (like “play”) Response: Parseable JSON
Object
Status: 404
Fail
2. Building Blocks
50
Test Case
ID
Input Expected Output Status
1. Select a building block (like
“Character”)
Length of ds.dump() increased
by 1.
Character object assigned a
timestamp, ID and a DOM
object.
Pass
2. Select a building block (like
“Character”)
Length of ds.dump() increased
by 1.
Character object not assigned
either of timestamp, ID and a
DOM object.
Fail
3. Select a building block (like
“Character”)
Length of ds.dump() not
increased by 1.
Character assigned a
timestamp, ID and a DOM
object.
Fail
4. Move a building block on workboard Building block is draggable.
Position of building block
updates and saves in
LocalStorage.
Pass
5. Move a building block on workboard Building block is not
draggable.
Fail
6. Move a building block on workboard Building block is draggable.
Position of building block does
not get updated and saved in
LocalStorage.
Fail
7. Right-click on buidling block. ContextMenu method is called
and context menu's DOM
objects' hidden classes are
removed.
Pass
8. Right-click on buidling block. ContextMenu method is called Fail
51
but context menu's DOM
objects' hidden classes are not
removed.
9. Right-click on buidling block. ContextMenu method is not
called.
Fail
3. Data Collection Items
Test Case
ID
Input Expected Output Status
1. (Create a new note)
Name, contents and tags for the note.
Note object gets saved in
LocalStorage.
Note's DOM object is
prepended in data's DOM
object.
Pass
2. (Create a new note)
Name, contents and tags for the note.
Note object gets saved in
LocalStorage.
Note's DOM object is not
prepended in data's DOM
object.
Fail
3. (Create a new note)
Name, contents and tags for the note.
Note object does not get saved
in LocalStorage.
Fail
4. (Create a new link)
Name, contents and tags for the link.
Link object gets saved in
LocalStorage.
Link's DOM object is
prepended in data's DOM
object.
Pass
5. (Create a new link)
Name, contents and tags for the link.
Link object gets saved in
LocalStorage.
Link's DOM object is not
prepended in data's DOM
object.
Fail
6. (Create a new link) Link object does not get saved Fail
52
Name, contents and tags for the link. in LocalStorage.
4. DataStore (LocalStorage)
Test Case
ID
Input Expected Output Status
1. Create a building block or data
collection item
Size of DataStore.localData
increases by one.
JSON format preserved.
Updated JSON saved to
LocalStorage.
Pass
2. Create a building block or data
collection item
Updated JSON not saved to
LocalStorage.
Fail
3. Create a building block or data
collection item
JSON format not preserved. Fail
4. Create a building block or data
collection item
Size of DataStore.localData
not increased by one.
Fail
5. Editor
Test Case
ID
Input Expected Output Status
1. Enter a paragraph in the editor and
wait for 5 seconds (auto-save).
Store paragraph in
LocalStorage.editor-
form.editor.
Pass
2. Enter a paragraph in the editor and
wait for 5 seconds (auto-save).
Unable to store paragraph in
LocalStorage.editor-
form.editor.
Fail
3. Browser refresh and
LocalStorage.editor-form.editor =
“<paragraph entered in the editor>”
Editor loads text from
LocalStorage.editor-
form.editor on load.
Pass
4. Browser refresh and
LocalStorage.editor-form.editor =
“<paragraph entered in the editor>”
Editor unable to load text from
LocalStorage.editor-
form.editor on load.
Fail
53
6. Note-taking REST API Server
Test Case
ID
Input Expected Output Status
1. HTTP Request with authentication
headers
Response: Parseable JSON
Object and does the required
work.
Status: 200
Pass
2. HTTP Request without authentication
headers
Response: Parseable JSON
Object, will not proceed
because of missing
authentication headers.
Status: 400
Pass
3. HTTP Request with incorrect
authentication headers
Response: Parseable JSON
Object, will not proceed
because of incorrect
authentication headers.
Status: 400
Pass
4 HTTP Request with parseable JSON
request body
Response: Parseable JSON
Object, proceeds and does the
required work.
Status: 200
Pass
5 HTTP Request with un-parseable
JSON request body
Response: null.
Status: 500
Fail
7. SMS Server
Test Case
ID
Input Expected Output Status
1. HTTP Request with text message Response: Parseable JSON
Object, broadcasting of the
message on project channel
Pass
54
without exceptions
Status: 200
2. HTTP Request with text message Response: Parseable JSON
Object, unable to broadcast the
message on project channel
because of exceptions
Status: 500
Fail
3. HTTP Request with text message Response: unable to parse
JSON
Status: 500
Fail
8. Compliance Testing Results of Complete Application using W3C's HTML Validator
Errors: 11 Errors
Warnings: 3 Warnings
Error No. Error Message Occurrence
1. Bad value X-UA-Compatible for attribute http-equiv on element
meta.
1
2. The cellspacing attribute on the table element is obsolete. Use CSS
instead.
2
3. The cellpadding attribute on the table element is obsolete. Use CSS
instead.
2
4. An img element must have an alt attribute, except under certain
conditions. For details, consult guidance on providing text
alternatives for images.
3
5. The valign attribute on the td element is obsolete. Use CSS instead. 1
6. Duplicate ID w-toggle. 1
7. Duplicate ID tool-modal-theme. 1
4.2.4 Error and Exception Handling
1. Dictionary & Thesaurus
55
Test Case
ID
Test Case Debugging Technique
1. Word: A dictionary word (like “play”) Chrome Devtools, Print Debugging,
Python's Debugger
2. Word: A non-dictionary word Chrome Devtools, Print Debugging,
Python's Debugger
3. Word: A dictionary word (like “play”) Chrome Devtools, Print Debugging,
Python's Debugger
4. Word: A dictionary word (like “play”) Chrome Devtools, Print Debugging,
Python's Debugger
2. Buidling Blocks
Test Case
ID
Test Case Debugging Technique
1. Select a building block (like
“Character”)
Chrome Devtools, Print Debugging
2. Select a building block (like
“Character”)
Chrome Devtools, Print Debugging
3. Select a building block (like
“Character”)
Chrome Devtools, Print Debugging
4. Move a building block on workboard Chrome Devtools, Print Debugging
5. Move a building block on workboard Chrome Devtools, Print Debugging
6. Move a building block on workboard Chrome Devtools, Print Debugging
7. Right-click on buidling block. Chrome Devtools, Print Debugging
8. Right-click on buidling block. Chrome Devtools, Print Debugging
9. Right-click on buidling block. Chrome Devtools, Print Debugging
3. Data Collection Items
Test Case
ID
Test Case Debugging Technique
1. (Create a new note)
Name, contents and tags for the note.
Chrome Devtools, Print Debugging
56
2. (Create a new note)
Name, contents and tags for the note.
Chrome Devtools, Print Debugging
3. (Create a new note)
Name, contents and tags for the note.
Chrome Devtools, Print Debugging
4. (Create a new link)
Name, contents and tags for the link.
Chrome Devtools, Print Debugging
5. (Create a new link)
Name, contents and tags for the link.
Chrome Devtools, Print Debugging
6. (Create a new link)
Name, contents and tags for the link.
Chrome Devtools, Print Debugging
4. DataStore (LocalStorage)
Test Case
ID
Test Case Debugging Technique
1. Create a building block or data
collection item
Chrome Devtools, Print Debugging
2. Create a building block or data
collection item
Chrome Devtools, Print Debugging
3. Create a building block or data
collection item
Chrome Devtools, Print Debugging
4. Create a building block or data
collection item
Chrome Devtools, Print Debugging
5. Editor
Test Case
ID
Test Case Debugging Technique
1. Enter a paragraph in the editor and
wait for 5 seconds (auto-save).
Chrome Devtools, Print Debugging, Manual
Inspection
2. Enter a paragraph in the editor and
wait for 5 seconds (auto-save).
Chrome Devtools, Print Debugging, Manual
Inspection
3. Browser refresh and Chrome Devtools, Print Debugging, Manual
57
LocalStorage.editor-form.editor =
“<paragraph entered in the editor>”
Inspection
4. Browser refresh and
LocalStorage.editor-form.editor =
“<paragraph entered in the editor>”
Chrome Devtools, Print Debugging, Manual
Inspection
4.2.5 Limitations of the solution
The following are the limitations of the proposed solutin:
1. Storing data in the browser's LocalStorage may lead to inconsistencies in data present at
other user's end.
2. Use of WebSockets provides messaging capabilities via a proxy server. This may result in
latency and also undetectable inconsistencies. A better solution would be to create a new
protocol for message like Peer-to-Peer.
3. Dependence on WebRTC only might leave the project incapable of running in old
browsers. The application should gracefully degrade to an alternative in case WebRTC
capabilities are missing.
4. Autocomplete functionality has bugs of its own which need to be fixed.
5. Planner's work board Document Object Model (DOM) is complex and keeps on getting
complex as the application is used. This at times makes the browser's rendering engine
slow.
6. Javascript is not optimized. It needs to be optimized to a great extent so that the
application can run smoothly even on mobile devices.
58
CHAPTER 5 – Findings & Conclusion
5.1 Findings
1. Human Computer Interaction and related studies have helped us understand various aspects
of developing a useful and usable tool. Without understanding the requirements from HCI
perspective, we would not have been able to come this far with our tool.
2. We have understood that Artificial Intelligence can play an important role in improving the
overall usability of the tool. However, its implementation has to be subtle so that it only
improves usability and does not irritate the user.
3. Open Source tools and libraries are instrumental in rapid development of functional
prototypes.
4. It is critical to clearly define the project problem statement sufficiently early on in the
project to facilitate timely completion of project.
5.3 Conclusion
Human Computer Interaction as a field was identified long time back but not many software
companies and individual developers have laid emphasis on it while developing software. This
has resulted in redundant but not so useful work in many fields. Human Computer Interaction is
an extremely important tool to make useful and usable software, and the way engineers continue
to make everyday life easy by employing technology, Human Computer Interaction is going to
play an important role in software development processes.
5.3 Future Work
In this semester, we have majorly focused on developing a conceptual model for our tool. On the
basis of that, we also developed a functional prototype and have validated it.
Future work for this project will improve:
1. Further validation of the existing conceptual model to find drawbacks and improve.
2. Making this application collaborative in real-time.
3. Adding more support tools for the user.
4. Improving overall usability and user-interface.
5. Publishing it as a web service.
59
References
1. Grudin, J. (1994). "Computer-Supported Cooperative Work: History and Focus"
from http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=291294
2. Introduction to NodeJS
from http://nodejs.org/
3. Why CSCW applications fail: problems in the design and evaluation of organization of
organizational interfaces, Jonathan Grudin
from http://dl.acm.org/citation.cfm?
id=62266.62273&coll=DL&dl=GUIDE&CFID=150339148&CFTOKEN=95744269
4. WebRTC
from http://www.w3.org/TR/webrtc/
5. RFC 6455
from http://tools.ietf.org/html/rfc6455
6. Google Wave Operational Transformation
from http://www.waveprotocol.org/whitepapers/operational-transform
7. What is HTML5?
from http://www.w3.org/html/wiki/FAQs#What_is_HTML5.3F
8. What is CSS?
from http://www.w3.org/Style/CSS/Overview.en.html
9. Functional JavaScript (Tech talk) by Douglas Crockfard at Blinkx
from http://www.blinkx.com/video/douglas-crockford-on-functional-
javascript/xscZz8XhfuNQ_aaVuyUB2A
10. “The Little JavaScripter” shows the relationship with Scheme in more detail
from http://www.crockford.com/javascript/little.html
11. Introduction to Meteor
from http://meteor.com
12. What is Local Storage and How To Use It by Christian Heilmann
from http://coding.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/
60
APPENDICES
Appendix A – Work Breakdown Structure
Aahana Tomar • Conducting surveys and experimental
studies for analysis.
• Analysis and evaluation of fiction writing
as an activity.
• Development of conceptual models.
• Designing the mock-ups for the User
Interface.
Vaidik Kapoor • Designing the mock-ups for the User
Interface.
• Conducting surveys and experimental
studies for analysis.
• Programming the back-end and the front-
end.
61
Appendix B – Report of Deeper Analysis of Existing Tools
Our analysis is divided mainly into the following categories which have certain parameters for
analyzing these tools:
• Features & Functionality
◦ Characters: tool for character development.
◦ Locations: tool for building different locations where different scenes of the story take
place.
◦ Items: tool for adding details to items of importance in the story.
◦ Scenes: tool for planning an incident that occurs in the story.
◦ Chapters: tool for planning the book's or story's parts in different chapters.
◦ Parts: tool for partitioning chapters.
• Support Tools
◦ Editor: like a document editor for supporting the writing process.
◦ Dictionary & Thesaurus
◦ Mind Mapping: for planning graphically.
◦ Research Collection & Organization:
◦ Exporting to other formats: if the tool allows exporting of work into other formats like MS
Office formats, LibreOffice formats, etc.
◦ Versioning: if the tool saves different versions of the work and allows rolling back or not.
◦ Collaboration: if the tool supports collaboration at all. If yes, what kind of collaboration:
synchronous or asynchronous.
• Overall Usability
◦ User Interface: definition of the user-interface: color-scheme, organization of tools and
information, navigation, overall design, etc.
◦ Ease-of-use: what is the learning curve involved. How easy is it for the user to start using
the software.
◦ Mobile Support: if the tool is supported on different mobile platforms or not. If yes, then
which platforms (native applications for iPad, iPhone, Android phones, Android tablets, etc.
or responsive web applications for all the mobile platforms).
62
Analysis
Story Book
Remarks:
• story book is a great tool for planning a story or a book.
• does not have tools for the writing process at all.
• Even though Story Book provides a lot of tools, those tools are easy-to-use individually and
difficult to use collectively.
• Strands (only in Story Book) are helpful.
• Charts are not helpful.
• Book View is a helpful feature to see how the whole project has shaped up.
• Makes use of colors to differentiate characters and other similar elements. Turns out to be useful
at times.
LitLift.com
Remarks:
• Provides a lot of flexibility with the available tools because the author can start the project from
any dimension.
• Lot of important tools are missing.
• Easy-to-use becaus:
◦ Good User Interface.
◦ Video support to get started using the tool.
Celtx
Remarks:
• For novels, comic books, A/V scripts, plays.
• Provides asynchronous collaboration which means that no two authors can edit at the same
time.
• Does not provide cognitive tools.
• Not easy-to-use because:
63
◦ Clumsy UI.
◦ Ambiguous navigation.
◦ Confusing tools.
My Writing Spot
Remarks:
• More of note-taking tool than a writing tool.
• No support for cognitive processes at all.
• Does not help much with writing as such, but the available tools are pretty easy-to-use.
• Has additional useful tools like sending documents to self by email.
• One of the only tools that provides comprehensive mobile support for all the major platforms.
Pressbooks
Remarks:
• More of a publishing platform, but also helps with writing.
• No support for cognitive processes at all.
• Comes with a really good editor.
• Easy-to-use:
◦ Neat UI.
◦ Inherits Wordpress, which is a really easy-to-use blogging platform.
• Has additional useful tools:
◦ Publishing platform.
◦ Analytics
Protagonize
Remarks:
• Stories, poems writing.
• Also a publishing platform.
• Claims to have asynchronous collaboration which is really difficult to locate and use.
• Addventure (branch out).
• Lack of good navigation and information organization.
64
• Cluttered user interface.
Rating of Tools
65
StoryBook LitLift.com Celtx.com My Writing Spot Pressbooks Protagonize
Feature / Functionality
Scenes 8
Chapters 7 5 4 4
Parts 7 7
Items 8 6
Characters 8 6
Locations 6 7
Tools
Dictionary / Thesaurus 6 5 5 8 5 5
Research Organization 4 3
Editor 3 8 6 10 8
Exporting Options 7 3 7 4 4
Versioning 8 8
Collaboration 5 6 4
Usability
User Interface 3 8 6 8 10 6
Ease-of-use 5 7 4 8 9 4
Mobile Support 8 10 9
Appendix C – Functional Prototype as Proof of Concept
Following are the screenshots of the functional prototype we have developed while working on this
project.
The main work board with basic story building blocks arranged on it.
66
New character modal window.
Basic WWSIWYG editor with autocomplete functionality.
67
Data Collection
68
Mobile App Prototype
69
Appendix D – Validation of Application Model and Early Prototypes
An early low fidelity prototype.
Once we designed few early low fidelity prototypes of various actions of the application, the validation
of those was the next logical step. Re-engineering of an already construed story was concluded to be
the most efficient and effective route. We overcame a lot of issues and many more important points of
focus cropped up in the process.
Learning Outcome
The planning section has two main constituents namely, Tools and References. The validation of the
application gave us an insight into these two important components and helped to design them more
efficiently in order to deduce the most out of it. Since we re-engineered a short story our main focus
was the development of Tools. Following is the detailed analysis of the same:
70
• Theme:
Theme is the central concept or topic that the author is trying to point out, discuss or explore via
the medium of his writing. Earlier, the moral that the reader takes away too was presumed to be
a part of the theme. Contemporary literary critics have established a difference between the
theme and the inference or thesis. The theme tool will include the following fields.
o Theme: This is the broad concept that lays foundation of a piece of fiction. Some
authors tend to cover more than one themes in one piece alone. In this field the author
can make notes and attach references and research the various issues to be covered and
knit them together at a later stage.
o Inference: In this field, the author can note down the various moral or subjective
perspectives he can establish along the theme that he has chosen.
o Conflict: Conflict is the driving force behind the actions and emotions of the
characters. There is no plot without conflict; hence conflict has an important position in
the structure of story writing. There are two kinds of conflicts.
Interpersonal Conflict- Human v/s Human, Human v/s Nature and Human v/s Society.
Internal Conflict- Human v/s Self.
In this field the author can plan at stretch this important aspect of fiction writing.
o Notes & References: Herein the author can attach references and research.
• Setting:
Often referred to as the story world, setting plays a crucial role and needs through planning .
Following are the components and hence the fields of Setting.
o Period: It is the era in which the story is set in. The components of this field may not be
explicitly mentioned but their implication forms the soul of the story.
o Culture: This field will have information regarding the culture of the strata of society
the story is based on.
o Backdrop: This field will contain information of the events prior to the events of the
story that actually lead to the circumstances which are not in control of the characters.
o Mood: This field will contain notes about the mood or the emotion that the author
wants the reader to feel while he is reading the story.
71
o Notes & References: Herein the author can attach references and research.
• Plot:
Plot is defines as the events that make up a story, particularly as they relate to one another in a
pattern, in a sequence, through cause and effect, how the reader views the story, or simply by
coincidence. One is generally interested in how well this pattern of events accomplishes some
artistic or emotional effect. Following are the fields of Plot.
o Exposition: The exposition introduces all of the main characters in the story. It shows
how they relate to one another, what their goals and motivations are, and the kind of
person they are. It lays ground for what is to unfold.
o Rising Action: This part helps recognize and reveal the conflicts of the characters to
another character or to himself. This also shows the progression of the story.
o Climax: This Part shows suspense (Turning point) in the novel or stories that surprises
the reader.
o Falling Action: this part demonstrates how the character had done accordingly in the
rising action. (If we have a rising action we have the falling action.)
o Resolution: This is the conclusion or the tying up of all the threads.
o Notes & References: Herein the author can attach references and research.
• Character:
A character is the representation of a person in a narrative work of art. In fiction characters
guide readers through their stories, helping them to understand plots and ponder themes. The
study of a character requires an analysis of its relations with all of the other characters in the
work. Following are the fields of Character.
o Name
o Personality Type: This includes the personality traits of the character.
o Physical Description
o Conflict
o Notes & References: Herein the author can attach references and research.
72
• Object:
An object is an inanimate thing that is of significance in the story with respect to the character
or the plot. It has the following fields.
o Name
o Significance: This field will contain information regarding the importance of the object
and its relationship with a character or place in the plot.
o Notes & References: Herein the author can attach references and research.
• Scene:
In fiction, a scene is a unit of drama. A sequel is what follows; an aftermath. Together, scene
and sequel provide the building blocks of plot for short stories, novels, and other forms of
fiction. Following are the fields of scene.
o Title
o Characters
o Backdrop: This field will contain information about the events prior to the scene.
o Description: This scene will contain information about the description or a short
summary of the scene.
o Dialogues: This field will have information about the important dialogues of the scene.
Dialogues are important because they add life to the scene.
o Notes & References: Herein the author can attach references and research.
73
Appendix E – Note-Taking REST API Documentation
API Authentication
Client Token
The API requires users of the API to require a client-token and pass it in the request headers as follows:
Request Headers:
• X-Major-Authentication: <your-client-token>
Every request must have this header with a valid client token or the API will reject the request by
sending the following response:
• 400 Forbidden
• Appropriate message.
User Authorization
Since this tool is for end-users who are required to create their accounts to use this service, the API also
requires every incoming API request to be authorized for the user using the client application.
This API uses Basic authentication over HTTPS (for security) for this purpose. You must pass the user
credentials in the request headers as follows:
• Authorization: Basic <base-64 encoded string in the form of username:password>
Resources
• Notes
• Tags
Notes API
Resource representation:
{
'name': '<string>',
'note': '<string>',
'tags': [
{
'tag': '<string>',
},
...
],
74
'files': [
{
'id': <integer>,
},
],
}
GET all the notes:
• Request URI: GET /api/note/
• Response:
◦ 200 OK
◦ List of notes
GET a note:
• Request URI: GET /api/note/<note-id>
• Response:
◦ 200 OK
◦ The requested note.
POST a note:
• Request URI: POST /api/note/
• Request body: JSON in the form of resource representation as defined above.
• Response:
◦ 201 Created
◦ The note that was created.
PUT a note:
• Request URI: PUT /api/note/<note-id>
• Request body: JSON in the form of resource representation as defined above.
• Response:
◦ 202 Updated
◦ The updated note.
75
Delete a note:
• Request URI: DELETE /api/note/<note-id>
• Request body: <empty>
• Response:
◦ 204 Removed
◦ <empty>
Tags API
Resource representation:
{
'tag': '<string>',
}
GET all the tags:
• Request URI: GET /api/tag/
• Response:
◦ 200 OK
◦ List of tags
GET a tag:
• Request URI: GET /api/tag/<tag-id>
• Response:
◦ 200 OK
◦ The requested tag.
CREATE a tag:
• Request URI: POST /api/tag/
• Request body: JSON in the form of resource representation as defined above.
• Response:
◦ 201 Created
76
◦ The tag that was created.
EDIT a tag:
• Request URI: PUT /api/tag/<note-id>
• Request body: JSON in the form of resource representation as defined above.
• Response:
◦ 202 Updated
◦ The updated tag.
Delete a tag:
• Request URI: DELETE /api/tag/<tag-id>
• Request body: <empty>
• Response:
◦ 204 Removed
◦ <empty>
Search API
The Search API allows developers to perform a full-text search through existing notes and return a list
of appropriate Notes.
Usage:
• Request URI: GET /api/search?q=<urlencoded-query-terms>
• Response:
◦ 200 OK
◦ List of valid notes resources.
77
BRIEF RESUME
Name : Aahana Tomar
Enrollment Number : 9503954
Email ID: : aahana142@gmail.com
Mobile Number : 9958053292
Significant Technical Achievements
Hospital Management System (Mini Project in Database Management)
An application comprising a database (MySQL) and a user-interface (HTML, CSS, PHP) for managing
day-to-day functioning of small nursing homes.
Scalable Storage System (Minor Project in Operating Systems)
A scalable storage platform developed to allow building of reliable and scalable storage systems to
provide users on a network space to store their personal files securely. The project was developed using
Bash scripting and PHP.
Imbroglio (Minor Project in Multimedia Development)
A short animated movie to represent the contemporary social and political system of the country. The
movie was developed using Adobe Flash and the designing was done using Adobe Photoshop and
Adobe Illustrator.
Significant Co-Curricular
Kriti Magazine, Co-Editor
Responsible for editing the content of college's bi-annual magazine Kriti.
Summer Internship
Completed my summer internship at HashStash Studio where I worked with the development team on
Trivial Analytics, a minimal game analytics system for collecting data about user behavior.
78
BRIEF RESUME
Name : Vaidik Kapoor
Enrollment Number : 9103471
Email ID: : kapoor.vaidik@gmail.com
Mobile Number : 8860679256
Significant Technical Achievements
Team Task Management Tool (Minor Project in Web Development)
A web application to allow teams to effectively manage tasks divided various team members.
Auto Text Generation (Minor Project in Compiler Design)
An algorithm to automatically generate paragraphs for a given topic by implementing N-Gram model
of speech and using a corpus populated from different repositories.
Google Apps Integration with Drupal (Google Summer of Code 2011)
Modules to provide various points of integration with the Google Apps service in Drupal, an open-
source Content Management System (CMS).
Password Protect (Mini Project in Algorithm Design)
A Firefox add-on that helps a user with keeping her different accounts safe by generating different
passwords for each account. The user has to remember just one password to access all of them.
Summer Internship
Completed my summer internship at Wingify Software Pvt. Ltd. where I worked with their
development team on a RESTful API for their flagship product, Visual Website Optimizer. Later, I also
designed and developed the architecture for Cross Browser A/B Test Validation system for Visual
Website Optimizer.
79

More Related Content

Similar to Report

Analysing and supporting the process of co-designing inquiry-based and techno...
Analysing and supporting the process of co-designing inquiry-based and techno...Analysing and supporting the process of co-designing inquiry-based and techno...
Analysing and supporting the process of co-designing inquiry-based and techno...musart
 
Understanding User Experience Workshop - Interlink Conference 2012
Understanding User Experience Workshop - Interlink Conference 2012Understanding User Experience Workshop - Interlink Conference 2012
Understanding User Experience Workshop - Interlink Conference 2012Lynne Polischuik
 
Software Project Management: Project Initiation
Software Project Management: Project InitiationSoftware Project Management: Project Initiation
Software Project Management: Project InitiationMinhas Kamal
 
Chapter 9 case study tools for visualising designs
Chapter 9 case study  tools for visualising designsChapter 9 case study  tools for visualising designs
Chapter 9 case study tools for visualising designsgrainne
 
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...All Things Open
 
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...Ju Lim
 
software engineering
software engineeringsoftware engineering
software engineeringTayfun Çelik
 
NEED FOR A SOFT DIMENSION
NEED FOR A SOFT DIMENSIONNEED FOR A SOFT DIMENSION
NEED FOR A SOFT DIMENSIONcsandit
 
1User Interface Development User Interface Dev.docx
1User Interface Development User Interface Dev.docx1User Interface Development User Interface Dev.docx
1User Interface Development User Interface Dev.docxfelicidaddinwoodie
 
Personas in Interaction Design
Personas in Interaction DesignPersonas in Interaction Design
Personas in Interaction DesignHans Põldoja
 
Ferreira
FerreiraFerreira
Ferreiraanesah
 
LaTICE 2016: Learner-Centered Design of Computing Education for All
LaTICE 2016: Learner-Centered Design of Computing Education for AllLaTICE 2016: Learner-Centered Design of Computing Education for All
LaTICE 2016: Learner-Centered Design of Computing Education for AllMark Guzdial
 
Project design guide
Project design guideProject design guide
Project design guidephilipkitheka
 
Project management from simple to complex
Project management   from simple to complexProject management   from simple to complex
Project management from simple to complexBui Huong
 
Odile the organisation designer
Odile the organisation designerOdile the organisation designer
Odile the organisation designerIntersection Group
 
Understanding Understanding: Implementing Design-Focused Service Initiatives ...
Understanding Understanding: Implementing Design-Focused Service Initiatives ...Understanding Understanding: Implementing Design-Focused Service Initiatives ...
Understanding Understanding: Implementing Design-Focused Service Initiatives ...Joe Marquez
 
A Practical Guide to Co-design
A Practical Guide to Co-design A Practical Guide to Co-design
A Practical Guide to Co-design Hoda Hamouda
 

Similar to Report (20)

Analysing and supporting the process of co-designing inquiry-based and techno...
Analysing and supporting the process of co-designing inquiry-based and techno...Analysing and supporting the process of co-designing inquiry-based and techno...
Analysing and supporting the process of co-designing inquiry-based and techno...
 
Understanding User Experience Workshop - Interlink Conference 2012
Understanding User Experience Workshop - Interlink Conference 2012Understanding User Experience Workshop - Interlink Conference 2012
Understanding User Experience Workshop - Interlink Conference 2012
 
Software Project Management: Project Initiation
Software Project Management: Project InitiationSoftware Project Management: Project Initiation
Software Project Management: Project Initiation
 
Chapter 9 case study tools for visualising designs
Chapter 9 case study  tools for visualising designsChapter 9 case study  tools for visualising designs
Chapter 9 case study tools for visualising designs
 
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
 
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
Ten Lessons Learnt to Drive and Transform Open Source Software User Experienc...
 
software engineering
software engineeringsoftware engineering
software engineering
 
Design case methods AECT 2013
Design case methods AECT 2013Design case methods AECT 2013
Design case methods AECT 2013
 
NEED FOR A SOFT DIMENSION
NEED FOR A SOFT DIMENSIONNEED FOR A SOFT DIMENSION
NEED FOR A SOFT DIMENSION
 
1User Interface Development User Interface Dev.docx
1User Interface Development User Interface Dev.docx1User Interface Development User Interface Dev.docx
1User Interface Development User Interface Dev.docx
 
Personas in Interaction Design
Personas in Interaction DesignPersonas in Interaction Design
Personas in Interaction Design
 
Ferreira
FerreiraFerreira
Ferreira
 
LaTICE 2016: Learner-Centered Design of Computing Education for All
LaTICE 2016: Learner-Centered Design of Computing Education for AllLaTICE 2016: Learner-Centered Design of Computing Education for All
LaTICE 2016: Learner-Centered Design of Computing Education for All
 
Project design guide
Project design guideProject design guide
Project design guide
 
Project management from simple to complex
Project management   from simple to complexProject management   from simple to complex
Project management from simple to complex
 
Odile the organisation designer
Odile the organisation designerOdile the organisation designer
Odile the organisation designer
 
Understanding Understanding: Implementing Design-Focused Service Initiatives ...
Understanding Understanding: Implementing Design-Focused Service Initiatives ...Understanding Understanding: Implementing Design-Focused Service Initiatives ...
Understanding Understanding: Implementing Design-Focused Service Initiatives ...
 
Jan Moons at WUD16
Jan Moons at WUD16Jan Moons at WUD16
Jan Moons at WUD16
 
A Practical Guide to Co-design
A Practical Guide to Co-design A Practical Guide to Co-design
A Practical Guide to Co-design
 
Critical analysis of portfolio
Critical analysis of portfolioCritical analysis of portfolio
Critical analysis of portfolio
 

Report

  • 1. FICTION AUTHORING Enrollment No. - 9503954, 9103471 Name of Students - Aahana Tomar, Vaidik Kapoor Name of Supervisor - Prof. Sanjay Goel May 2013 Submitted in complete fulfillment of the Degree of Bachelor of Technology in Information Technology & Computer Science Engineering Department of Computer Science Engineering & Information Technology Jaypee Insititue of Information Technology, NOIDA 1
  • 2. TABLE OF CONTENTS Chapter Number Topic Page Number Cover Page 1 Table of Contents 2 Student Declaration 4 Certificate from Supervisor 5 Acknowledgment 6 Summary 7 List of Figures 8 List of Tables 9 List of Symbols and Acronyms 10 Chapter 1 Introduction 11 - 19 1.1 General Introduction 1.2 Problem Statement 1.3 Empirical Study 1.4 Solution Approach 1.5 Approach to problem in terms of technology and platform to be used. 1.6 Support for Novelty Chapter 2 Literature Survey 20 - 31 2.1 List of all the sources for formulation of problem statement 2.2 Summary of Relevant Papers Chapter 3 Analysis, Design and Modeling 32 - 44 3.1 Overall Description of the Project 3.2 Functional Requirements 3.3 Non-Functional Requirements 3.4 Logical Database Requirements 2
  • 3. 3.5 Design Diagrams 3.6 Risk Analysis 3.7 Risk Mitigation Plan Chapter 4 Implementation Details 45 - 56 4.1 Implementation Details and Issues 4.2 Testing Chapter 5 Findings & Conclusion 57 5.1 Findings 5.2 Conclusion 5.3 Future Work References 58 Appendices 59 - 70 Appendix A – Work Breakdown Structure Appendix B – Report of Deeper Analysis of Existing Tools Appendix C – Functional Prototypes as Proof of Concept Appendix D – Validation of Application Model and Early Prototypes 3
  • 4. DECLARATION We, hereby, declare that this submission is our own work and that, to the best of our knowledge and belief, it contains no material previously published or written by another person nor material which has been accepted for the award of any other degree or diploma of the university or other institute of higher learning, except where due acknowledgment has been made in the text. Place: Date: Signature: Name: Aahana Tomar, Vaidik Kapoor Enrollment No.: 9503954, 9103471 4
  • 5. CERTIFICATE This is to certify that the work titled “Fiction Authoring” submitted by “Aahana Tomar” & “Vaidik Kapoor” in partial fulfillment for the award of degree of “Bachelor of Technology” of “Jaypee Institute of Information Technology University, Noida” has been carried out under my supervision. This work has not been submitted partially or wholly to any other University or Institute for the award of this or any other degree or diploma. Signature of Supervisor: Name of Supervisor: Designation: Date: Prof. Sanjay Goel Head of Department (CSE/IT) 5
  • 6. ACKNOWLEDGEMENT First and foremost, I would like to thank Prof. Sanjay Goel, our project supervisor. We are immensely grateful for all the guidance he has given us. His direction was essential to shape our project. We humbly thank him for all his patience as we worked during the semester. We would also like to thank Arshiya Lekhi for voluntarily participating in a writing exercise that helped us understand challenges people face while writing collaboratively. And last, but not the least, we would like to thank all our peers who shared their suggestions and criticisms as our project progressed. Signature of student: Name of student: Enrollment Number: Date: Aahana Tomar, Vaidik Kapoor 9503954, 9103471 6
  • 7. SUMMARY Our project, ‘Fiction Authoring’, is an application which comprises set of tools for book authors (specifically fiction authors) to assist them with collaboratively planning their stories, helping them with their cognitive processes and authoring the complete book. This tool will be a web service and will be mobile compatible. We observed that their aren't enough tools to assist authors with writing and planning their books effectively. In addition to that, there are existing tools have no support for writing books collaboratively. Through this project, we have tried to explore the challenges in developing a tool for fiction authors who want to write individually and collaboratively. Signature of student: Name: Date: Aahana Tomar, Vaidik Kapoor Signature of Supervisor: Name: Date: Prof. Sanjay Goel 7
  • 8. LIST OF FIGURES Figure Page No. Use Case Diagram 39 Class Diagram 40 Inter-relationship Graph 42 Integration Graph 45 8
  • 9. LIST OF TABLES Table Page No. Functional Requirements 33 Non-functional Requirements 34 Logical Database Requirements 35 Risk Analysis 41 Risk Mitigation 43 Testing Plan 47 Component decomposition and type of testing required 49 Test Cases 50 Error and Exception Handling 54 9
  • 10. LIST OF SYMBOLS & ACRONYMS HCI Human Computer Interaction CSCW Computer Supported Collaborative Word HTML5 Hyper Text Markup Language v5 CSS Cascading Style Sheets JS Javascript WebRTC Web Real-Time Communication UX User Experience UI User Interface DOM Document Object Model API Application Programming Interface WYSIWYG What You See Is What You Get AJAX Asynchronous Javascript And XML DOS Denial of Service JSON Javascript Object Notation 10
  • 11. CHAPTER 1 – Introduction 1.1 General Introduction The need to develop tools for collaboration in different spheres of human activities with humans not co-located was felt long back in the early 1980s. Since then, a very focused group of researchers have been working towards understanding the human needs in the context of using computers for supporting human activities and collaboration. [1] The field that deals with this kind of study is called Computer Supported Co-operative Work. CSCW is a generic term, which combines the understanding of the way people work in groups with the enabling technologies of computer networking, and associated hardware, software, services and techniques. [2] Since then, numerous tools for collaboration in organizations, document writing, office automation, project management, etc. have been developed and deployed and notable success has been achieved as well. Even though developers and researchers have tried to cover different human activities, creative writing specifically is an activity that has not been looked into very closely. A lot of work has been done towards developing efficient synchronous editors for real-time collaboration, however these editors mainly aid document creation in real-time and don't support the cognitive processes in anyway that lead to creation of those documents. Our intention is to simplify the activity of collaborative writing where not just document preparation is the activity in focus but the activity of planning/ideation along with document preparation collectively is considered one and important. 1.2 Problem Statement As a part of this project, our aim is to identify the needs of authors who write fiction articles and stories and develop an efficient tool to aid this activity. We have specifically chosen fiction authors to be our audience because fiction writing is a truly abstract process and cannot be easily structured. Authors decide their own working methodologies and processes. They cannot be limited to a strictly structured environment. Initially our objective was to develop an application that would aid collaborative writing a work 11
  • 12. of fiction by two geographically distant authors. Upon exaggerated research and analysis it has been concluded that it is imperative that we first construct an application for a single author to personally plan and write a book and use this as a platform to support collaboration. Hence for this stage alone, collaboration has been kept as a long term objective. Currently, we have to understand the processes involved when a single author is structuring a piece of fiction. Upon understanding we need to identify the problems occurring in a real world scenario and create an application that yields solutions to those problems. This will help the author to plan and write with ease and efficiency. Great amount of research and understanding is involved to gain insight into the cognitive aspects of writing. The support tools should render to every need of the author and the application has to be intelligent enough to steer the author in the right direction without thrusting an iron clad structure on him. 1.3 Empirical Study 1.3.1 Collaborative Writing Activity in the Same Space: We conducted an activity where two people had to collaborate on an article (fiction) in the same space (i.e. the same room at the same time). The objective of the activity was to observe the whole activity of writing a fiction story as to how the participants behave in the activity, what do they talk about, what do they discuss, how do they discuss ideas, what difficulties do they face, what tools and resources do they require, etc. The outcome of these observations helped us understand the needs of authors in general and further helped us understand how can we develop an environment where authors can collaborate without being in the space. Learning Outcome: • All the collaborators should have a similar mindset and the way they think. • All the collaborators should have a similar writing style. • They generally plan before they start writing. This plan will not always be externally 12
  • 13. represented. From person to person, this differs. • The cognitive process of doing a creative activity is one of the most important things that the active participants in the activity do. In this activity, this happened with the help of: ◦ Discussions. ◦ Use of paper and pen to explain ideas through drawings to each other. ◦ Use of the internet to do research. • Sometimes in a collaborative activity like such, a collaborator is so involved in his own thinking that he/she sometimes forgets to listen to what the other person is saying. • Resolution of conflicts is a difficult process. In case of different spaces, it can be even more difficult. • They needed resources to refer to quickly at the time of writing – internet, thesaurus, dictionary, etc. 1.3.2 1st Validation Book Name: The Lady, Or The Tiger? Author: Frank R. Stockton This, extensively anthologized short story was published in The Century Magazine in 1882. It is set in the 6th Century A.D. In this exercise, our goal is to envisage Stockton’s process of planning and writing this short story, try to trace it to our Application and to further identify the glitches in it. The story stands firmly on two pillars- the historical pretext and a deep understanding of the human psyche, with the latter having had no need to be researched. Learning Outcome: While doing this activity, few shortcomings of the Application came to light. The hairline difference between event and scene became clearer after conducting this activity. An event is a fact; it is either the background or the foreground of a scene. Scenes and events are 13
  • 14. parallel to each other with the latter following a chronological order. Events provide a reason or understanding to a scene. Scenes have an agenda, they have a conflict but events are pure facts. With reference to the story discussed: Events: • The Semi-barbaric king enjoys deploying his wild fancies to a few matters to public affairs. He has therefore established a unique method to judge the innocence or guilt of the deliquescent of his kingdom, wherein they are left to a chance of fate and punished or rewarded immediately. This florid ritual has become a source of entertainment to both the king and his pupils. • The king’s daughter falls in love with a royal subject, who is immediately imprisoned. • He too has to face the trial now. • The princess, true to her nature, somehow retrieves the truth of what lies behind each door. • But she is tormented because she cannot decide if she could see her lover be wedded to another woman and let this truth scathe her for the rest of her life. She is faced with a question that does not seem to have any answer. • On the day of the trial she manages to convey to him which door to open • The author does not reveal the choice made by the princess, instead leaves it on the reader to judge. Who came out of the door, The Lady or the Tiger? Scenes: There is only one scene in the story: The day of the trial where in the subjects looks at nobody but the princess in the look of the eye asked her the question and with the gesture of a hand she too returned the answer. He promptly followed her and opened the door. Conclusion: As a result of this exercise, we understood that Events as a dedicated building block is necessary for planning purposes. Therefore, Events and Scenes will have the following fields: 14
  • 15. Scene: Characters, Location, Backdrop, Agenda, Conflict, Action, Dialogues Event: Characters, Location, Dialogues, Backdrop, Conflict 1.3.3 2nd Validation Book Name: Veronica Decides to Die Author: Paulo Coelho Veronika Decides to Die is a novel by Paulo Coelho. It tells the story of 24-year-old Slovenian Veronika, who appears to have everything in life going for her, but who decides to kill herself. Learning Outcome The Application so far, has been structured for a short story and even though it will cater a novel on the superficial level, problems crop up when one starts to dig in deeper. For instance, one can plan out each character, the setting, the theme extensively, using this Application. Problems will occur in planning out the Plot. There will be a plot to the entire story but here will be sub plots in every chapter too. There will be scenes and events that will have to be strung carefully. The events of the novel will follow a chronology irrespective of the chapter and the point of view from which the novel is written. The scenes and subplots would be developed using these events as foundation. This book has been written from the point of view of a third person and has a linear approach. Chapter-wise planning needs to be given more thought. 1.4 Solution Approach So far, we have been working towards understanding fiction writing, the issues associated with fiction writing in single-user environments and the requirements for developing a multi-user environment for the same. In the process, we have conducted activities and deeply analyzed 15
  • 16. existing single-user tools to get a deeper knowledge of the processes involved in writing fiction. However, analysis for developing a multi-user environments is quite different as compared to analysis for development of single-user environments because in the latter, only a single user is involved but when more than one user is involved, the evaluation procedure gets more based on the methodologies of social psychology and anthropology. A single-user application may get away with appealing to a kind of “lowest common denominator”. CSCW applications will often have to appeal to every possible denominator. [3] To tackle the problems with multi-user environments as stated above along with developing an effective tool for authors who want to write fiction is a complex process. Furthermore, we will not be able to propose an effective solution unless we solve the more fundamental problem of not having a good authoring tool for single authors only. Therefore, we have decided to first develop a single-user fiction authoring tool that will support the fundamental processes of writing fiction out-of-the-box. This will be the main objective of our project for this semester. After developing and successfully validating this tool to an acceptable extent (i.e. by validating the tool by a couple of actual authors), we will work towards adding real-time features for enabling this application to be used by more than one authors. These objectives shall be achieved while working on our project in the next semester. We understand that fiction writing is a creative process and cannot be discretely structured or designed because every author has her own style and processes of writing a story. Therefore, we have continuously kept ourselves involved with trying to learn more and more about the structured studies about fiction writing available publicly. In addition to this, we have conducted several activities to understand the whole process better and have been working towards developing a model for this tool. Earlier, we had divided our project in four main discrete phases, according to which we have already completed Phase 1 and are in the middle of Phase 2. However after doing more studies about our project, we have come to understand that there are going to be recurring activities. Therefore, we have revised our phases as follows: 16
  • 17. • Phase 2 ◦ On the basis of the analysis done so far, prepare a conceptual model for the application. ◦ Dry-run the mock-ups through the process of re-engineering existing short stories. Iterate until an acceptable conceptual model is achieved. ◦ Start working on a basic functional prototype for desktops only, but with design decisions made for mobile devices as well. • Phase 3 ◦ Start developing the prototype of the mock-up decided in Phase 2 for desktop and mobile devices (to follow the “Mobile First” theory). ◦ Validate the prototype with volunteers. Study the issues faced by actual users and iterate until satisfied. • Phase 4 ◦ Start working towards taking the prototype to the stage of a fully functional tool by integrating with the back-end. ◦ Start validating the tool with real audience. ◦ Iterate to improve features, performance and usability. 1.5 Approach to problem in terms of technology and platform to be used Platform: Our preference of platform is the Web. The Web is the new platform. With minimal effort, it will enable us to reach a larger audience by enabling us to easily bring the tool to desktops and mobiles at the same time. Mobile is an important platform today and cannot be ignored. A considerable percentage of the third world countries' population's first hand experience of operating a computer happens through mobile devices. The Web is continuously evolving with a fast pace and it is attracting a lot of attention. With this continuous evolution, we will get enough resources to develop this tool and improve it with time as newer technologies are introduced. Web Real-Time Communication: WebRTC is an API definition being drafted by the World 17
  • 18. Wide Web Consortium (W3C) and jointly in the IETF with a chartered working group.[4] The goal of WebRTC is to enable applications such as voice calling, video chat and P2P file sharing without plugins. WebRTC is what our tool will base on to implement VoIP like features for communication between authors. WebSocket: WebSocket is a web technology providing for bi-directional, full-duplex communications channels over a single TCP connection. The WebSocket API is being standardized by the W3C, and the WebSocket protocol has been standardized by the IETF as RFC 6455. [5] WebSockets will form the base for the implementation of Operational Transformation, a set of algorithms developed by Google for their Google Wave project. [6] HTML5: HTML5 contains powerful capabilities for Web-based applications with more powerful interaction, video support, graphics, more styling effects, and a full set of APIs. [7] Cascading Style Sheets: CSS3 is a simple mechanism for adding style (e.g., fonts, colors, spacing) to Web documents. [8] JavaScript: is a prototype-based scripting language that is dynamic, weakly typed and has first- class functions. It is a multi-paradigm language, supporting object-oriented, imperative, and functional [9][10] programming styles. NodeJS: Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. [2] Meteor: Meteor is a platform built on top of NodeJS to allow development of modern web applications with real-time capabilities, hot code pushes, etc. [11] MeteorJS is makes use of NodeJS and Comet and a lot of other existing libraries. 18
  • 19. 1.6 Support for Novelty Technology finds its application in every field and it has brought convenience to every aspect of our lives. Its unique feature of continuous evolution and simplicity in complexity makes it indispensable. Several software have been developed which help amateur writers compose works of fiction. Unfortunately these software have not been able to create a niche for themselves in the authors community and fiction authors to be precise. Enhancing the usability of the existing software and helping authors to collaborate a fiction novel makes this project novel. The significance of this problem resides in the bare fact that there is a meager number of Computer Supported Multiple-Author books. Geographically distant yet eager to write authors form the audience of this project. The tool developed, will not be a stringently structured environment which kills creativity. Objectives like: user friendly interface, effective tools, skillfully segregated work spaces, real time editor, audio-video aided chat application, support for mobile devices and tablets will help the authors to contribute to their novel rather than getting entangled in unnecessary confusion. 19
  • 20. CHAPTER 2 – Literature Survey 2.1 List of all the sources for formulation of problem statement Papers: 1. Responsive Web Design 2. Responsive Web Design: What It Is and How To Use It 3. Mozilla UX Research: Save for Later 4. Awareness Displays and Social Motivation for Coordinating Communication 5. Issues in the Design of Computer Support for and Commenting 6. Awareness and Coordination in Shared Workspaces 7. Computer Supported Co-operative Work: History and Focus 8. Why CSCW applications fail: problems in the design and evaluation of organization of organizational interfaces Books: 1. Aristotle's Poetics Existing Tools: 1. MediaWiki 2. EtherPad 3. Google Wave 4. Drammatica 5. StoryBook 6. LitLift.com 7. Celtx.com 8. My Writing Spot 9. Pressbooks 10. Protagonize 11. Scrivener 12. Mendeley (not a writing tool but source of inspiration) 13. Writer's Cafe 20
  • 21. 2.2 Summary of Relevant Papers Title Responsive Web Design Authors Ethan Marcotte Year of Publication 2010 Publishing Details A List Apart Web Link http://www.alistapart.com/articles/responsive-web-design/ Summary The article introduces the concept of Responsive Web Design and how it is required today to design web applications that can effectively run on all kinds of devices. Today, we need to build applications for all the platforms out there. Building applications for all the platforms is possible however the heterogeneity of platforms makes it extremely difficult to make the same application for different platforms. This article talks about making use of the power of HTML5 & CSS3 to build responsive web applications using Media Queries that change the size, organization and appearance of their layouts and essential UI elements. The article further gives examples of how Media Queries can be used to ask the browser to interpret specific CSS files on the basis of width of the device and width the of the browser's viewport. Finally, the article introduces the concept of Grid based layouts for designing responsive web applications. Title Responsive Web Design: What It Is and How To Use It Authors Kayla Knight Year of Publication 2011 Publishing Details Smashing Magazine 21
  • 22. Web Link http://coding.smashingmagazine.com/2011/01/12/guidelines-for- responsive-web-design/ Summary The author discusses that limiting your web application to only desktop hurts the audience you can reach and serve. There is a need of building responsive web applications to allow your application to penetrate better within your target audience by supporting various devices with various screen sizes. The author discusses how making everything flexible from the ground-up can be a right way of solving the multi-device-single-code-base problem. However, images break layouts until HTML5 was introduced. Now, even images can be flexibly resized and sliced. The author further talks about how and what screen sizes should be taken care of on the basis of importance of audience, importance of platform and other parameters. The author also discusses how to handle complex elements like images, navigation, articles, etc. Different mobile device also pose an orientation problem which can not be solved with the help of CSS3 Media Queries. The author also highlights the importance of what to hide elements on mobile devices and show only the necessary elements because of lack of space. Title Mozilla UX Research: Save for Later Authors Brian Groudan 22
  • 23. Year of Publication 2012 Publishing Details Mozilla User Experience Blog Web Link https://blog.mozilla.org/ux/2012/10/save-for-later/ Summary The Firefox for Android team wanted to know why bookmarks usage was minimal on mobile devices and if users would be more likely to bookmark if the feature was designed differently. Therefore, the User Experience (UX) team at Mozilla conducted a study to identify the issues. The UX team at Mozilla began their study by first trying to identify what are bookmarks used for by the people and what purpose do bookmarks solve for the end-user. They conducted a study of how users use bookmarks in their day-to-day life by asking the participants of the study to record their actions by themselves. As a result of this study, the research team identified various purposes for which bookmarks in Firefox is used. They also identified other services which are used instead of Firefox's bookmarks for the same purposes. They also analyzed user behavior data on the basis of data collected by Test Pilot to understand how quantitatively Firefox's bookmark feature is used by a user everyday. On the basis of the results of these studies, the team of researchers identified the requirements and the design goals of re-engineering bookmarks in Firefox to make bookmarking and saving links for later use easy, intuitive, highly available, centralized. The project's code name is Dropzilla. This report helped us understand how to understand the needs of our target audience i.e. authors and how to conduct the study and how to proceed further to draw conclusions and design tools for our own project. Title The concept of activity as a basic unit of analysis for CSCW 23
  • 24. research Authors Kari Kuuti Year of Publication 1991 Publishing Details Proceedings of the Second European Conference on Computer-Supported Cooperative Work Web Link http://dl.acm.org/citation.cfm?id=1241929 Summary This paper introduces Activity Theory as the basic unit of analysis for understanding activities important for application of CSCW. The basic idea is that there exists a "fundamental type" of context, which is called an activity. It is meaningless to study essentially human qualities using a smaller object of research, because without that basic context one cannot grasp the essence of the phenomenon. The activities in which humans participate are the basic units of development and human life, and thus form a foundation of the study of all contextuality. Activities - an individual can participate in several at the same time - have the following properties: • an activity has a material object and activities can be distinguished according to their objects. The transformation of the object towards some desired state or in some direction motivates the existence of an activity. • an activity is a collective phenomenon. • an activity has an active subject, who understands the motive of the activity. This subject can be individual or collective. Not all 24
  • 25. participants involved in an activity necessarily understand the motive of the activity in which they are participating or even recognize the existence of it. In this case they are not active subjects of the activity. • an activity exists in a material environment and transforms it. • an activity is a historically developing phenomenon. • contradictions are the force behind the development of an activity. • an activity is realized through conscious and purposeful actions by participants. • the relationships within an activity are culturally mediated. It is suggested here that Activity Theory offers a promising framework for CSCW research, because the concept of the activity as the basic unit of work analysis seems to meet a number of acute demands expressed by CSCW researchers. Title Aristotle's Poetics Authors Aristotle, Gerald F. Else (Translator) Year of Publication 1957 Publishing Details University of Michigan Press Web Link http://www.flipkart.com/aristotle-s-poetics- 0472061666/p/itmczzaagpuzubgg Summary The project, Collaborative Fiction Authoring rests on two interdependent tires, namely, collaboration and authoring. One has to study the fundamental requirements and rules of both collaboration and authoring at depth, and create a tool that effectively and effortlessly facilitates two or more authors to compose a piece of work together. 25
  • 26. Aristotle’s Poetics is a dependable and comprehensive resource which explores and objectively lays down the rules for writing a piece of fiction. An extensively dissected study of the same will help us understand the entire process of writing and henceforth develop a more efficient tool. Following is the learning outcome: • The centre stones of the book are: ◦ Every work of fiction is an imitation of men in their action. ◦ The plot should be continuous and all the elements should tie down at climax. ◦ Catharsis or, outburst of emotions like fear, pity etc. should be the outcome of the story. • Narrative (the author enforces his opinion on the reader eg: novels) and Dramatic (the reader is free to form his own opinion about the characters and events, eg: plays) are the two forms of writing and our tool should be able to render help to create both. • Work of fiction is divided into 6 parts: ◦ Plot - chronological events of the story. ◦ Characters - the actors who carry the story. ◦ Thought - theme of the story. ◦ Diction- style of delivering dialogues in case of plays. ◦ Melody - mood of the play. ◦ Spectacle - the set up in case of a play and the surroundings in case of a story. • Plot: ◦ It must be complete with a beginning, middle and end. ◦ Complex plots are of the best kind which arouse emotions like pity, fear etc. • Procedure for plot construction: 26
  • 27. ◦ Author should visualize the actions of the story as vividly as possible. ◦ Should even try acting out the events as he writes them. ◦ Routine the over-all plot of the story and then flesh out the episodes. ◦ Author should write about focused incidents. • Characters ◦ Should be complex and interesting who arouse curiosity. ◦ Appropriate portrayal. ◦ Life - like and true to their nature ◦ Consistent. Even the inconsistency should be consistent. • Should consist of complication and denouement. Aristotle's method raises the question of whether fiction authoring can be studied in the same way as the natural sciences. Though there are some benefits to Aristotle's method, the ultimate answer seems to be "no". Art often thrives and progresses by questioning the assumptions or laws that a previous generation has accepted. Title Issues in the Design of Computer Support for Co-authoring and Commenting Authors Christine M. Neuwith, David S. Kraufer, Ravinder Chandhok, James H. Morris Year of Publication 1990 Publishing Details Proceedings of the Conference on Computer-Supported Cooperative Work 1990 Web Link http://dl.acm.org/citation.cfm?id=99354 Summary There are two important aspects to collaboration as highlighted by this paper: social an cognitive. 27
  • 28. The social aspect of collaboration involves the process of co-ordination to a great extent. We have to consider the activities the writers have to perform by the virtue of which they have to work together rather that alone. Of these, support for definition of social roles and support for communication plans are important in the context of our project. Cognitive aspects of an activity are decided more specifically by the kind of activity taking place. They also depend on the active participants of the activity. Some task specific activities involve drawing, jotting, sketching, writing, etc. When writers (experienced or inexperienced) work in environments that do not have support for these activities, they report frustration as these activities are essential tools for them. Many of the writers resort to paper to produce intermediate representations, such as plans for drafts, trees depicting structural characteristics of an outline or draft, etc. These writers often want to create these as quickly as possible and they often treat these only as temporary sketches, doodles, etc. Title Awareness and Coordination in Shared Workspaces Authors Paul Dourish, Victoria Bellotti Year of Publication 1992 Publishing Details Proceedings of the Conference on Computer-Supported Cooperative Work 1992 Web Link http://dl.acm.org/citation.cfm?id=143468 Summary This paper highlights the importance of awareness in shared workspaces. Awareness is an understanding of the activities of others, which provides a context for your own activity. The authors emphasize that awareness information is always required to coordinate group activities, whatever the task domain. Although we deal largely here with collaborative text editing, other collaborative activities can benefit equally from the approach we outline. 28
  • 29. The awareness problem has been dealt with for so many years but all the existing ways have time and again proved that the user who provides the information does not directly benefit. A widely used mechanism, referred to as Informational, is to provide explicit facilities through which collaborators inform each other of their activities. For instance, wiki such as MediaWiki ask users to provide text for an “edit log” which describes the nature of changes. In this case, it is clearly visible that the writer has to enter the “edit log” for the benefit of others and not for self. A second mechanism, which we refer to as role restrictive, arises from explicit support for roles in collaborative systems. A role describes an individual's relationships to the shared work objects and to other participants, and is typically linked to a set of operations which can be performed. In a shared authoring system, for instance, an “author” role might be associated with the read, write, create, delete and edit operations, while a “reviewer” might be limited to read and annotate. Though this mechanism is capable of keeping track of actions performed per user but there is a significant trade-off with respect to benefits. The price of heightened awareness for the group is clearly restriction in the potential activities of individuals. All of these systems clearly embody an assumption that a simple awareness of others' activity needs to be augmented with other explicit, or restrictive mechanisms for ensuring an easy collaboration, such as annotations, role assignment, access rights and so forth. 29
  • 30. Title Why CSCW applications fail: problems in the design and evaluation of organization of organizational interfaces Authors J. Grudin Year of Publication 1988 Publishing Details Proceedings of the Conference on Computer-Supported Cooperative Work 1988 Web Link http://dl.acm.org/citation.cfm? id=62266.62273&coll=DL&dl=GUIDE&CFID=150339148&CFTOKEN =95744269 Summary Many systems, applications, and features that support cooperative work share two characteristics: a significant investment has been made in their development, and their successes have consistently fallen far short of expectations. The important points that the paper highlights about failure of CSCW applications are: • The application fails because it requires that some people do additional work, while those people are not the ones who perceive a direct benefit from the use of the application. • The design process fails because our intuitions are poor for multi- user applications -- decision-makers see the potential benefits for people similar to themselves, but don’t see the implications of the fact that extra work will be required of others. • We fail to learn from experience because these complex applications introduce almost insurmountable obstacles to meaningful, generalizable analysis and evaluation. • The best solution is to try to insure that everyone benefits directly from using the application. This may mean building in additional features. It certainly means eliminating or’ minimizing the extra work required of anyone, or rewarding them for doing it. • The experience, and very likely the track record, of a development 30
  • 31. manager considering a CSCW application is generally based on single-user applications. Intuition may be a far more reliable. guide to single-user applications -- a manager with good intuition may quickly get a feel for the user’s experience with a word processor, spreadsheet, or so forth. But a typical CSCW application will be used by a range of user types -- people with different backgrounds and job descriptions, all of whom may have to participate in one way or another for the application to succeed. • Evaluation of CSCW applications requires a very different approach, based on the methodologies of social psychology and anthropology. It concludes that investing resources adequate to the solution of the problems, developing the appropriate research and development methodologies, finding niches where the problems don't arise or where applications will succeed in spite of them, and adequately preparing users for the introduction of the applications are all approaches that may lead to success. CSCW applications will have to be more “group-friendly” than systems have been. They will change the organization, but more gradually. For this reason. the focus of CSCW will shift to user interface issues to minimize the disruption and additional work required of any user of the application. 31
  • 32. CHAPTER 3 – Analysis, Design and Modeling 3.1 Overall description of the project We have identified that the tool will be broadly divided into two parts: • Planner – the part that will be used by the user to ideate and plan the book. • Editor – to write and manage the book. The above two parts are broadly identify what a user will be doing i.e. first plan/ideate the book and then write. According to the study and analysis we have done so far, we have identified certain features for the above two parts/modules. Writing fiction is a creative process and every author has her own style, processes and methods. To come up with one tool for the same is non-trivial. Therefore, we have decided that our efforts must be in the direction of understanding the process of fiction writing and then trying to make a tool that is very flexible. Both the modules of the tool will have a dedicated screen for themselves such that the visible screen will have features and functionality of that module. Planner: The planner will allow the user to ideate, brainstorm and plan their book. Planning a book is a complex process and no single author does that in the same way. So many tools have been developed to help authors write. However, their adoption have failed because of the complexity involved. We are trying to make the planning process extremely simple for authors by trying to dampen the learning curve. Planning a book is an abstract process and one might approach it from any angle. This part Editor: The editor will be more of a document editor, though with some new features and most of the features of existing document editors missing because they are not required. This will allow the author to concentrate more on writing and the new features will promise to help the author write. Global Features: This is not a separate important module but a collection of help tools like 32
  • 33. Dictionary & Thesaurus. There will be some features we have identified that will be common to both the planner and the editor. These tools will be of general purpose that can be used both with the planner and the editor. 3.2 Functional Requirements Dictionary & Thesaurus • User input of word or phrase • Dictionary API • In-browser Context Menu References • Files • Links Verification • URL Meta Data Parser • Notes • Media • Device Camera • Device Microphone • Video & Audio Conversion Story Planner • User Content • References • Drag and Drop • Drag-able & Zoom-able Workspace • Modal Windows • Timeline Slider & Organizer Editor • WYSIWYG Editor • Table of Contents Organizer Global Requirements • Diff Generator • Version Generator • Client-Side Change Detection • Auto Save 33
  • 34. 3.3 Non-Functional Requirements The tool shall be intuitive and easy-to-use. • Consistent in design. • Usable. • Ergonomic. The tool shall be flexible for users to use it the way they want and must not impose restrictions. The tool shall be extensible enough to add new features and functionality. The tool shall store the user's data reliably. • Auto-save feature must detect changes and save the data at regular intervals of 5 seconds if changes are made. • If internet connection is not available, the tool must store the changes in the browser's LocalStorage database. [12] The tool shall be highly available. • Robust servers • Systems should be as safe as possible from DOS/DDOS attacks. • Low down-times. The tool shall be responsive so that the user does not have to wait long for actions to complete. • Extensive use of AJAX to avoid large responses from the server. • All responses must reach the client within 2 seconds (not in-case of networks with extremely low latency). The tool shall be secure. • HTTPS • Secure and slow password hashing • Secure storage systems (encryption must be employed). The tool shall save versions of project data. • Previous versions up to a certain number of days depending on storage constraints. The tool shall make fast API calls for dictionary • For all practical purposes, response 34
  • 35. and thesaurus. to API calls should be served within 2 seconds. 3.4 Logical Database Requirements 3.4.1 Database Design Table Name Columns and their types Comments users • user_id (int, primary key) • email (varchar) • name (var_char) • image (longtext) • registration_date (timestamp) • password (varchar) • last_login (timestamp) • For storing user data. reference_types • reference_type_id (int, primary key) • reference_type (varchar) • For storing types of references. Ex: audio, image, link, etc. • Mostly static unless we choose to support new kinds of references. references • reference_id (int, primary key) • project_id (int, foreign key [projects.project_id]) • title (varchar) • reference_type_id (int, foreign key [reference_types.reference_type_id]) • value (longtext) • length (int) • size (int) • For storing references. 35
  • 36. • notes (longtext) • timestamp (timestamp) tags • tag_id (int, primary key) • project_id (int, foreign key [projects.project_id]) • tag (varchar) • timestamp (timestamp) • For storing unique tags. reference_tags • reference_id (int, foreign key [references.reference_id]) • tag_id (int, foreign key [tags.tag_id]) • timestamp (timestamp) • For storing relationships between tags and references. projects • project_id (int, primary key [projects.project_id]) • user_id (int, foreign key [users.user_id]) • project_name (varchar) • timestamp (timestamp) • For storing project information. object_types • object_type_id (int, primary key) • object_type_slug (varchar) • object_type_name (varchar) • For storing object types (or tools). • Mostly static unless we choose to add new tools. objects • object_id (int, primary key) • object_type_id (int, foreign key [object_types.object_type_id]) • project_id (int, foreign key [projects.project_id]) • title (varchar) • structured_content (JSON) • notes (longtext) • For storing objects created using tools. 36
  • 37. • order (int) object_relationshi ps • object_1_id (int, foreign key [objects.object_id]) • object_2_id (int, foreign key [objects.object_id]) • notes (longtext) • For storing relationships between different objects. object_references • object_id (int, foreign key [objects.object_id]) • reference_id (int, foreign key [references.reference_id) • timestamp (timestamp) • For storing relationships between objects and existing references. chapter_documen ts • chapter_id (int, primary key) • project_id (int, foreign key [projects.project_id]) • chapter_name (varchar) • content (longtext) • chapter_order (int) • part_id (int, foreign key [parts.part_id]) • timestamp (timestamp) • For storing chapters created using the editor and which part do they belong to. parts • project_id (int, foreign key [projects.project_id]) • part_id (int, primary key) • part_name (varchar) • part_order (int) • timestamp (timestamp) • For storing information of parts. history • history_id (int, primary key) • table_name (varchar) • primary_key (int) • timestamp (timestamp) • reverse_patch (longtext) • For storing versions of all types of data that needs to be versioned. 37
  • 38. 3.4.2 Frequency of Use • Maximum average of 1 write / 5 seconds / live-user (safe to assume because the auto- save feature will attempt to save every 5 seconds only if the user has changed any data on the client-side). • Assuming a minimum average of database reads at this stage is not possible. This can only be approximated by examining user behavior. 3.4.3 Accessing Capabilities • JSON data type. • Fast I/O for fast AJAX calls. 3.4.4 Data Entities and their Relationships • users have 1-to-many relationship with projects. • projects have 1-to-many relationship with references. • references have many-to-many relationship reference_tags. • projects have 1-to-many relationship with objects. • references have many-to-many relationship with objects. • projects have 1-to-many relationship with parts. • parts have 1-to-many relationship with chapters. • objects have many-to-many relationship with themselves. 3.4.5 Data Retention Constraints Users will use this tool for their work, meaning they will be saving their lives work and research. It is essential for this tool to handle their data reliably and make sure that the their data remains safe. 38
  • 39. The tool must: • Retain all the project data until and unless the user chooses to delete it. • Retain N latest older versions of various components of the project. The value of N will depend on the constraints of the systems used in projection. 3.5 Design Diagrams 3.5.1 Use Case Diagram Actors: • Author 39
  • 41. 3.6 Risk Analysis Risk Id Classification (Acc to SEI taxonomy) Description of Risk Risk Area Probability Impact RE (P* I) 1 Personnel Management (Development Environment) Irregularity → schedule will be affected Personnel Related H (5) H (5) 25 2 Deliverability (Development Environment) Excessive evolution of problem statement → delay in project deliverable Project Scope H (5) H (5) 25 3 Usability (Development Environment) Constrain on data models → risk of limiting user friendliness Performance M (3) H (5) 15 4 Capacity (Development Environment) Wide scope of functionality of project → unrealistic expectations from the project Project Scope L (1) H (5) 5 5 Personnel Management (Development Environment) One partner on long vacation → that part of work was not available Personnel Related L (1) H (5) 5 41
  • 42. 6 Interfaces (Product Engineering) Random input from user → desired outcome is not achieved. External Inputs L (1) H (5) 5 7 Usability (Development Environment) Complex input format → reduced/erroneous input provided External Inputs L (1) M (3) 3 S.No. Risk Area No. of Risk Statements Weights (In + Out) Total Weight Priority 1 Performance 4 9 + 9 + 3 21 1 2 Personnel Related 2 3 + 9 12 2 42
  • 43. 3 External Inputs 2 3 + 9 12 3 4 Project Scope 1 3 + 3 6 4 Risk Statement Risk Area Priority of Risk Area in IG Constraint on accuracy → risk of limiting user friendliness Performance 1 Wide scope of functionality of project → unrealistic expectations from the project Project Scope 4 Excessive evolution of problem statement → delay in project deliverable Project Scope 4 One partner on long vacation → that part of work was not available. Personnel Related 2 Irregularity → schedule will be affected Personnel Related 2 No input from user → project execution Freezes External Inputs 3 Complex input format → reduced/erroneous input provided External Inputs 3 3.7 Risk Mitigation Risk Mitigation Approaches Date Started Date to Complete Owner Additional Resources needed for Mitigation Irregularity → schedule will be affected Conduct weekly review meeting with mentor and other students working under 28 – 01 - 13 26 – 04 – 13 Mentor Presence of other groups under our mentor during meetings. 43
  • 44. same mentor. Excessive evolution of problem statement → delay in project deliverable Settle at a point and begin implementation to ensure completion. 02 – 02 – 13 20 – 04 - 13 Mentor None Constraint on data models → risk of limiting user friendliness. Repeatedly validate project model with real-world applications and real users. 01 – 04 - 13 27 – 05 - 13 Aahana, Vaidik None 44
  • 45. CHAPTER 4 – Implementation and Testing 4.1 Implementation details and issues 4.1.1 Implementation 4.1.1.1 Modeling For allowing the author to approach her story with ease without getting imposed by any structure we have designed for this application, we have approached the design of our application in such a way that the author may choose to do whatever she wants at any given time. The above approach allows the author to begin working on a project from any direction i.e. the author may choose to: 45
  • 46. • start by planning and then go on to write. • start by writing and plan while she writes. • start by collecting notes and references and uses the tool for only that purpose along with writing. There can be many such combination of approaches and the user may choose whichever she is the most comfortable with. 4.1.1.2 Prototyping On the basis of the above design, we designed some functional fidelity paper prototypes for our application, reviewed it and revised it for improving it according to our understanding. The prototypes are available in Appendix #. 4.1.1.3 Validation We validated our prototypes and application's model by rewriting an existing story with our tools prototypes. In this process, we identified numerous issues with our prototypes and learned new things about the fiction writing process. The activity's report is available in Appendix #. 4.1.1.4 Implementation With the results of our validation process, we started working on a medium fidelity interactive prototype of the planning section. This prototype will also be used in getting our application's model validated by actual users. 4.1.1.5 Issues • Existing model needs more thorough validation to freeze the fundamental tools needed for story planning. • Application stores data only in the browser's LocalStorage and IndexedDB stores. • Actual authors are required for thorough validation and insights in the process of writing. Unfortunately, we haven't been able to get in touch authors. • Development for mobile devices is essential but at the same time it is more work and 46
  • 47. complex as well. Even though we have taken the easier route of developing a responsive application, it is still complex and time consuming. 4.1.2 Debugging Our application gets data from users actions and behavior inside the browser. Furthermore, we use HTML5 specification's LocalStorage and IndexedDB to store our data inside the browser first to handle latency and data loss issues. For debugging. we have extensively used the following tools: • Chrome Dev Tools • Chrome Javascript Debugger • Javascript's console.log() function for variable inspection at different steps. 4.1.3 Error and Exception Handling There are many areas of our application that have required us to handle generic exceptions fired by Javascript. Those cases are as follows: 1. Internet is not available: appropriate messages are shown when features that require the Internet are used. 2. Dictionary & Thesaurus service is down: application looks for words in a cache with an appropriate message saying that the service is temporarily down and we are showing cached results. 3. Link added in Data Collection is invalid: the user is warned for the same. 4. LocalStorage does not exist: restarts the application from the very beginning and handles situations where data is expected. 4.2 Testing and Evaluation 4.2.1 Testing Plan Type of Test Will test be performed? Comments Software Component Unit Testing Yes The application is mainly divided into three main • Planner • Data Collection 47
  • 48. components – editor, planner and data collection. Apart from this, a custom LocalStorage ORM has been written for the application. Note-taking service REST API server exists to receive HTTP requests when the user interacts with the mobile app. The SMS server exists to receive HTTP requests when a particular number receives a message from the author. This message is further processed and broadcasted to users. • Editor • DataStore ORM • Dictionary & Thesaurus • Note-taking REST API Server • SMS Server Integration Testing Yes Our application's modules are inter dependent. • Editor • Planner • DataStore ORM • Dictionary & Thesaurus Performance Testing No At the current stage of development, our aim is to focus on development more than performance. Stress Testing No At this stage, we have not identified stress points for this application as feature development is higher priority. Compliance Yes Since our application is a web • Complete 48
  • 49. Testing application, we have made sure that our client-side code complies with all W3C's HTML5 specification. We have verified this using the W3C compliance validator. Application Security Testing No Feature development is higher on priority. Furthermore, all communications will happen using the HTTPS (Secure) protocol, which will eliminate most of the security loop-holes. Load Testing Yes LocalStorage affects performance of the browser depending upon the size of the data it is holding. • Planner • Dictionary & Thesaurus • Data Collection Testing Environment Software Used Description Operating System (Server): Fedora 17 The application is hosted on an Nginx web server, running on Fedora 17. Operating System (Client): Windows 7, Mac OS X and Fedora 17 The application has been opened and tested manually in different operating systems. Browser: Google Chrome 20.0.18, Firefox 19 Nightly The application has been opened and tested manually in a few different browsers. The automated tests are run inside the browsers. Tests are written in Javascript. Web Server: Nginx, NodeJS HTTP Static The web server software that is used is NodeJS HTTP Static, which sits behind Nginx that acts as a proxy. 4.2.2 Component decomposition and type of testing required 49
  • 50. S. No. Components that require testing Type of testing required Technique for writing test cases 1. Dictionary & Thesaurus Unit Testing Black Box 2. Building Block Unit Testing Black Box 3. Data Collection Items Unit Testing Black Box 4. DataStore (LocalStorage) Unit Testing Black Box 5. Editor Unit Testing Black Box 6. Complete Application Compliance Testing W3C's HTML5 specification validator 4.2.3 Test Cases 1. Dictionary & Thesaurus Test Case ID Input Expected Output Status 1. Word: A dictionary word (like “play”) Response: Parseable JSON Object Status: 200 Pass 2. Word: A non-dictionary word Response: Parseable JSON Object Status: 404 Pass 3. Word: A dictionary word (like “play”) Response: Parseable JSON Object Status: 500 Fail 4. Word: A dictionary word (like “play”) Response: Parseable JSON Object Status: 404 Fail 2. Building Blocks 50
  • 51. Test Case ID Input Expected Output Status 1. Select a building block (like “Character”) Length of ds.dump() increased by 1. Character object assigned a timestamp, ID and a DOM object. Pass 2. Select a building block (like “Character”) Length of ds.dump() increased by 1. Character object not assigned either of timestamp, ID and a DOM object. Fail 3. Select a building block (like “Character”) Length of ds.dump() not increased by 1. Character assigned a timestamp, ID and a DOM object. Fail 4. Move a building block on workboard Building block is draggable. Position of building block updates and saves in LocalStorage. Pass 5. Move a building block on workboard Building block is not draggable. Fail 6. Move a building block on workboard Building block is draggable. Position of building block does not get updated and saved in LocalStorage. Fail 7. Right-click on buidling block. ContextMenu method is called and context menu's DOM objects' hidden classes are removed. Pass 8. Right-click on buidling block. ContextMenu method is called Fail 51
  • 52. but context menu's DOM objects' hidden classes are not removed. 9. Right-click on buidling block. ContextMenu method is not called. Fail 3. Data Collection Items Test Case ID Input Expected Output Status 1. (Create a new note) Name, contents and tags for the note. Note object gets saved in LocalStorage. Note's DOM object is prepended in data's DOM object. Pass 2. (Create a new note) Name, contents and tags for the note. Note object gets saved in LocalStorage. Note's DOM object is not prepended in data's DOM object. Fail 3. (Create a new note) Name, contents and tags for the note. Note object does not get saved in LocalStorage. Fail 4. (Create a new link) Name, contents and tags for the link. Link object gets saved in LocalStorage. Link's DOM object is prepended in data's DOM object. Pass 5. (Create a new link) Name, contents and tags for the link. Link object gets saved in LocalStorage. Link's DOM object is not prepended in data's DOM object. Fail 6. (Create a new link) Link object does not get saved Fail 52
  • 53. Name, contents and tags for the link. in LocalStorage. 4. DataStore (LocalStorage) Test Case ID Input Expected Output Status 1. Create a building block or data collection item Size of DataStore.localData increases by one. JSON format preserved. Updated JSON saved to LocalStorage. Pass 2. Create a building block or data collection item Updated JSON not saved to LocalStorage. Fail 3. Create a building block or data collection item JSON format not preserved. Fail 4. Create a building block or data collection item Size of DataStore.localData not increased by one. Fail 5. Editor Test Case ID Input Expected Output Status 1. Enter a paragraph in the editor and wait for 5 seconds (auto-save). Store paragraph in LocalStorage.editor- form.editor. Pass 2. Enter a paragraph in the editor and wait for 5 seconds (auto-save). Unable to store paragraph in LocalStorage.editor- form.editor. Fail 3. Browser refresh and LocalStorage.editor-form.editor = “<paragraph entered in the editor>” Editor loads text from LocalStorage.editor- form.editor on load. Pass 4. Browser refresh and LocalStorage.editor-form.editor = “<paragraph entered in the editor>” Editor unable to load text from LocalStorage.editor- form.editor on load. Fail 53
  • 54. 6. Note-taking REST API Server Test Case ID Input Expected Output Status 1. HTTP Request with authentication headers Response: Parseable JSON Object and does the required work. Status: 200 Pass 2. HTTP Request without authentication headers Response: Parseable JSON Object, will not proceed because of missing authentication headers. Status: 400 Pass 3. HTTP Request with incorrect authentication headers Response: Parseable JSON Object, will not proceed because of incorrect authentication headers. Status: 400 Pass 4 HTTP Request with parseable JSON request body Response: Parseable JSON Object, proceeds and does the required work. Status: 200 Pass 5 HTTP Request with un-parseable JSON request body Response: null. Status: 500 Fail 7. SMS Server Test Case ID Input Expected Output Status 1. HTTP Request with text message Response: Parseable JSON Object, broadcasting of the message on project channel Pass 54
  • 55. without exceptions Status: 200 2. HTTP Request with text message Response: Parseable JSON Object, unable to broadcast the message on project channel because of exceptions Status: 500 Fail 3. HTTP Request with text message Response: unable to parse JSON Status: 500 Fail 8. Compliance Testing Results of Complete Application using W3C's HTML Validator Errors: 11 Errors Warnings: 3 Warnings Error No. Error Message Occurrence 1. Bad value X-UA-Compatible for attribute http-equiv on element meta. 1 2. The cellspacing attribute on the table element is obsolete. Use CSS instead. 2 3. The cellpadding attribute on the table element is obsolete. Use CSS instead. 2 4. An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images. 3 5. The valign attribute on the td element is obsolete. Use CSS instead. 1 6. Duplicate ID w-toggle. 1 7. Duplicate ID tool-modal-theme. 1 4.2.4 Error and Exception Handling 1. Dictionary & Thesaurus 55
  • 56. Test Case ID Test Case Debugging Technique 1. Word: A dictionary word (like “play”) Chrome Devtools, Print Debugging, Python's Debugger 2. Word: A non-dictionary word Chrome Devtools, Print Debugging, Python's Debugger 3. Word: A dictionary word (like “play”) Chrome Devtools, Print Debugging, Python's Debugger 4. Word: A dictionary word (like “play”) Chrome Devtools, Print Debugging, Python's Debugger 2. Buidling Blocks Test Case ID Test Case Debugging Technique 1. Select a building block (like “Character”) Chrome Devtools, Print Debugging 2. Select a building block (like “Character”) Chrome Devtools, Print Debugging 3. Select a building block (like “Character”) Chrome Devtools, Print Debugging 4. Move a building block on workboard Chrome Devtools, Print Debugging 5. Move a building block on workboard Chrome Devtools, Print Debugging 6. Move a building block on workboard Chrome Devtools, Print Debugging 7. Right-click on buidling block. Chrome Devtools, Print Debugging 8. Right-click on buidling block. Chrome Devtools, Print Debugging 9. Right-click on buidling block. Chrome Devtools, Print Debugging 3. Data Collection Items Test Case ID Test Case Debugging Technique 1. (Create a new note) Name, contents and tags for the note. Chrome Devtools, Print Debugging 56
  • 57. 2. (Create a new note) Name, contents and tags for the note. Chrome Devtools, Print Debugging 3. (Create a new note) Name, contents and tags for the note. Chrome Devtools, Print Debugging 4. (Create a new link) Name, contents and tags for the link. Chrome Devtools, Print Debugging 5. (Create a new link) Name, contents and tags for the link. Chrome Devtools, Print Debugging 6. (Create a new link) Name, contents and tags for the link. Chrome Devtools, Print Debugging 4. DataStore (LocalStorage) Test Case ID Test Case Debugging Technique 1. Create a building block or data collection item Chrome Devtools, Print Debugging 2. Create a building block or data collection item Chrome Devtools, Print Debugging 3. Create a building block or data collection item Chrome Devtools, Print Debugging 4. Create a building block or data collection item Chrome Devtools, Print Debugging 5. Editor Test Case ID Test Case Debugging Technique 1. Enter a paragraph in the editor and wait for 5 seconds (auto-save). Chrome Devtools, Print Debugging, Manual Inspection 2. Enter a paragraph in the editor and wait for 5 seconds (auto-save). Chrome Devtools, Print Debugging, Manual Inspection 3. Browser refresh and Chrome Devtools, Print Debugging, Manual 57
  • 58. LocalStorage.editor-form.editor = “<paragraph entered in the editor>” Inspection 4. Browser refresh and LocalStorage.editor-form.editor = “<paragraph entered in the editor>” Chrome Devtools, Print Debugging, Manual Inspection 4.2.5 Limitations of the solution The following are the limitations of the proposed solutin: 1. Storing data in the browser's LocalStorage may lead to inconsistencies in data present at other user's end. 2. Use of WebSockets provides messaging capabilities via a proxy server. This may result in latency and also undetectable inconsistencies. A better solution would be to create a new protocol for message like Peer-to-Peer. 3. Dependence on WebRTC only might leave the project incapable of running in old browsers. The application should gracefully degrade to an alternative in case WebRTC capabilities are missing. 4. Autocomplete functionality has bugs of its own which need to be fixed. 5. Planner's work board Document Object Model (DOM) is complex and keeps on getting complex as the application is used. This at times makes the browser's rendering engine slow. 6. Javascript is not optimized. It needs to be optimized to a great extent so that the application can run smoothly even on mobile devices. 58
  • 59. CHAPTER 5 – Findings & Conclusion 5.1 Findings 1. Human Computer Interaction and related studies have helped us understand various aspects of developing a useful and usable tool. Without understanding the requirements from HCI perspective, we would not have been able to come this far with our tool. 2. We have understood that Artificial Intelligence can play an important role in improving the overall usability of the tool. However, its implementation has to be subtle so that it only improves usability and does not irritate the user. 3. Open Source tools and libraries are instrumental in rapid development of functional prototypes. 4. It is critical to clearly define the project problem statement sufficiently early on in the project to facilitate timely completion of project. 5.3 Conclusion Human Computer Interaction as a field was identified long time back but not many software companies and individual developers have laid emphasis on it while developing software. This has resulted in redundant but not so useful work in many fields. Human Computer Interaction is an extremely important tool to make useful and usable software, and the way engineers continue to make everyday life easy by employing technology, Human Computer Interaction is going to play an important role in software development processes. 5.3 Future Work In this semester, we have majorly focused on developing a conceptual model for our tool. On the basis of that, we also developed a functional prototype and have validated it. Future work for this project will improve: 1. Further validation of the existing conceptual model to find drawbacks and improve. 2. Making this application collaborative in real-time. 3. Adding more support tools for the user. 4. Improving overall usability and user-interface. 5. Publishing it as a web service. 59
  • 60. References 1. Grudin, J. (1994). "Computer-Supported Cooperative Work: History and Focus" from http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=291294 2. Introduction to NodeJS from http://nodejs.org/ 3. Why CSCW applications fail: problems in the design and evaluation of organization of organizational interfaces, Jonathan Grudin from http://dl.acm.org/citation.cfm? id=62266.62273&coll=DL&dl=GUIDE&CFID=150339148&CFTOKEN=95744269 4. WebRTC from http://www.w3.org/TR/webrtc/ 5. RFC 6455 from http://tools.ietf.org/html/rfc6455 6. Google Wave Operational Transformation from http://www.waveprotocol.org/whitepapers/operational-transform 7. What is HTML5? from http://www.w3.org/html/wiki/FAQs#What_is_HTML5.3F 8. What is CSS? from http://www.w3.org/Style/CSS/Overview.en.html 9. Functional JavaScript (Tech talk) by Douglas Crockfard at Blinkx from http://www.blinkx.com/video/douglas-crockford-on-functional- javascript/xscZz8XhfuNQ_aaVuyUB2A 10. “The Little JavaScripter” shows the relationship with Scheme in more detail from http://www.crockford.com/javascript/little.html 11. Introduction to Meteor from http://meteor.com 12. What is Local Storage and How To Use It by Christian Heilmann from http://coding.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/ 60
  • 61. APPENDICES Appendix A – Work Breakdown Structure Aahana Tomar • Conducting surveys and experimental studies for analysis. • Analysis and evaluation of fiction writing as an activity. • Development of conceptual models. • Designing the mock-ups for the User Interface. Vaidik Kapoor • Designing the mock-ups for the User Interface. • Conducting surveys and experimental studies for analysis. • Programming the back-end and the front- end. 61
  • 62. Appendix B – Report of Deeper Analysis of Existing Tools Our analysis is divided mainly into the following categories which have certain parameters for analyzing these tools: • Features & Functionality ◦ Characters: tool for character development. ◦ Locations: tool for building different locations where different scenes of the story take place. ◦ Items: tool for adding details to items of importance in the story. ◦ Scenes: tool for planning an incident that occurs in the story. ◦ Chapters: tool for planning the book's or story's parts in different chapters. ◦ Parts: tool for partitioning chapters. • Support Tools ◦ Editor: like a document editor for supporting the writing process. ◦ Dictionary & Thesaurus ◦ Mind Mapping: for planning graphically. ◦ Research Collection & Organization: ◦ Exporting to other formats: if the tool allows exporting of work into other formats like MS Office formats, LibreOffice formats, etc. ◦ Versioning: if the tool saves different versions of the work and allows rolling back or not. ◦ Collaboration: if the tool supports collaboration at all. If yes, what kind of collaboration: synchronous or asynchronous. • Overall Usability ◦ User Interface: definition of the user-interface: color-scheme, organization of tools and information, navigation, overall design, etc. ◦ Ease-of-use: what is the learning curve involved. How easy is it for the user to start using the software. ◦ Mobile Support: if the tool is supported on different mobile platforms or not. If yes, then which platforms (native applications for iPad, iPhone, Android phones, Android tablets, etc. or responsive web applications for all the mobile platforms). 62
  • 63. Analysis Story Book Remarks: • story book is a great tool for planning a story or a book. • does not have tools for the writing process at all. • Even though Story Book provides a lot of tools, those tools are easy-to-use individually and difficult to use collectively. • Strands (only in Story Book) are helpful. • Charts are not helpful. • Book View is a helpful feature to see how the whole project has shaped up. • Makes use of colors to differentiate characters and other similar elements. Turns out to be useful at times. LitLift.com Remarks: • Provides a lot of flexibility with the available tools because the author can start the project from any dimension. • Lot of important tools are missing. • Easy-to-use becaus: ◦ Good User Interface. ◦ Video support to get started using the tool. Celtx Remarks: • For novels, comic books, A/V scripts, plays. • Provides asynchronous collaboration which means that no two authors can edit at the same time. • Does not provide cognitive tools. • Not easy-to-use because: 63
  • 64. ◦ Clumsy UI. ◦ Ambiguous navigation. ◦ Confusing tools. My Writing Spot Remarks: • More of note-taking tool than a writing tool. • No support for cognitive processes at all. • Does not help much with writing as such, but the available tools are pretty easy-to-use. • Has additional useful tools like sending documents to self by email. • One of the only tools that provides comprehensive mobile support for all the major platforms. Pressbooks Remarks: • More of a publishing platform, but also helps with writing. • No support for cognitive processes at all. • Comes with a really good editor. • Easy-to-use: ◦ Neat UI. ◦ Inherits Wordpress, which is a really easy-to-use blogging platform. • Has additional useful tools: ◦ Publishing platform. ◦ Analytics Protagonize Remarks: • Stories, poems writing. • Also a publishing platform. • Claims to have asynchronous collaboration which is really difficult to locate and use. • Addventure (branch out). • Lack of good navigation and information organization. 64
  • 65. • Cluttered user interface. Rating of Tools 65 StoryBook LitLift.com Celtx.com My Writing Spot Pressbooks Protagonize Feature / Functionality Scenes 8 Chapters 7 5 4 4 Parts 7 7 Items 8 6 Characters 8 6 Locations 6 7 Tools Dictionary / Thesaurus 6 5 5 8 5 5 Research Organization 4 3 Editor 3 8 6 10 8 Exporting Options 7 3 7 4 4 Versioning 8 8 Collaboration 5 6 4 Usability User Interface 3 8 6 8 10 6 Ease-of-use 5 7 4 8 9 4 Mobile Support 8 10 9
  • 66. Appendix C – Functional Prototype as Proof of Concept Following are the screenshots of the functional prototype we have developed while working on this project. The main work board with basic story building blocks arranged on it. 66
  • 67. New character modal window. Basic WWSIWYG editor with autocomplete functionality. 67
  • 70. Appendix D – Validation of Application Model and Early Prototypes An early low fidelity prototype. Once we designed few early low fidelity prototypes of various actions of the application, the validation of those was the next logical step. Re-engineering of an already construed story was concluded to be the most efficient and effective route. We overcame a lot of issues and many more important points of focus cropped up in the process. Learning Outcome The planning section has two main constituents namely, Tools and References. The validation of the application gave us an insight into these two important components and helped to design them more efficiently in order to deduce the most out of it. Since we re-engineered a short story our main focus was the development of Tools. Following is the detailed analysis of the same: 70
  • 71. • Theme: Theme is the central concept or topic that the author is trying to point out, discuss or explore via the medium of his writing. Earlier, the moral that the reader takes away too was presumed to be a part of the theme. Contemporary literary critics have established a difference between the theme and the inference or thesis. The theme tool will include the following fields. o Theme: This is the broad concept that lays foundation of a piece of fiction. Some authors tend to cover more than one themes in one piece alone. In this field the author can make notes and attach references and research the various issues to be covered and knit them together at a later stage. o Inference: In this field, the author can note down the various moral or subjective perspectives he can establish along the theme that he has chosen. o Conflict: Conflict is the driving force behind the actions and emotions of the characters. There is no plot without conflict; hence conflict has an important position in the structure of story writing. There are two kinds of conflicts. Interpersonal Conflict- Human v/s Human, Human v/s Nature and Human v/s Society. Internal Conflict- Human v/s Self. In this field the author can plan at stretch this important aspect of fiction writing. o Notes & References: Herein the author can attach references and research. • Setting: Often referred to as the story world, setting plays a crucial role and needs through planning . Following are the components and hence the fields of Setting. o Period: It is the era in which the story is set in. The components of this field may not be explicitly mentioned but their implication forms the soul of the story. o Culture: This field will have information regarding the culture of the strata of society the story is based on. o Backdrop: This field will contain information of the events prior to the events of the story that actually lead to the circumstances which are not in control of the characters. o Mood: This field will contain notes about the mood or the emotion that the author wants the reader to feel while he is reading the story. 71
  • 72. o Notes & References: Herein the author can attach references and research. • Plot: Plot is defines as the events that make up a story, particularly as they relate to one another in a pattern, in a sequence, through cause and effect, how the reader views the story, or simply by coincidence. One is generally interested in how well this pattern of events accomplishes some artistic or emotional effect. Following are the fields of Plot. o Exposition: The exposition introduces all of the main characters in the story. It shows how they relate to one another, what their goals and motivations are, and the kind of person they are. It lays ground for what is to unfold. o Rising Action: This part helps recognize and reveal the conflicts of the characters to another character or to himself. This also shows the progression of the story. o Climax: This Part shows suspense (Turning point) in the novel or stories that surprises the reader. o Falling Action: this part demonstrates how the character had done accordingly in the rising action. (If we have a rising action we have the falling action.) o Resolution: This is the conclusion or the tying up of all the threads. o Notes & References: Herein the author can attach references and research. • Character: A character is the representation of a person in a narrative work of art. In fiction characters guide readers through their stories, helping them to understand plots and ponder themes. The study of a character requires an analysis of its relations with all of the other characters in the work. Following are the fields of Character. o Name o Personality Type: This includes the personality traits of the character. o Physical Description o Conflict o Notes & References: Herein the author can attach references and research. 72
  • 73. • Object: An object is an inanimate thing that is of significance in the story with respect to the character or the plot. It has the following fields. o Name o Significance: This field will contain information regarding the importance of the object and its relationship with a character or place in the plot. o Notes & References: Herein the author can attach references and research. • Scene: In fiction, a scene is a unit of drama. A sequel is what follows; an aftermath. Together, scene and sequel provide the building blocks of plot for short stories, novels, and other forms of fiction. Following are the fields of scene. o Title o Characters o Backdrop: This field will contain information about the events prior to the scene. o Description: This scene will contain information about the description or a short summary of the scene. o Dialogues: This field will have information about the important dialogues of the scene. Dialogues are important because they add life to the scene. o Notes & References: Herein the author can attach references and research. 73
  • 74. Appendix E – Note-Taking REST API Documentation API Authentication Client Token The API requires users of the API to require a client-token and pass it in the request headers as follows: Request Headers: • X-Major-Authentication: <your-client-token> Every request must have this header with a valid client token or the API will reject the request by sending the following response: • 400 Forbidden • Appropriate message. User Authorization Since this tool is for end-users who are required to create their accounts to use this service, the API also requires every incoming API request to be authorized for the user using the client application. This API uses Basic authentication over HTTPS (for security) for this purpose. You must pass the user credentials in the request headers as follows: • Authorization: Basic <base-64 encoded string in the form of username:password> Resources • Notes • Tags Notes API Resource representation: { 'name': '<string>', 'note': '<string>', 'tags': [ { 'tag': '<string>', }, ... ], 74
  • 75. 'files': [ { 'id': <integer>, }, ], } GET all the notes: • Request URI: GET /api/note/ • Response: ◦ 200 OK ◦ List of notes GET a note: • Request URI: GET /api/note/<note-id> • Response: ◦ 200 OK ◦ The requested note. POST a note: • Request URI: POST /api/note/ • Request body: JSON in the form of resource representation as defined above. • Response: ◦ 201 Created ◦ The note that was created. PUT a note: • Request URI: PUT /api/note/<note-id> • Request body: JSON in the form of resource representation as defined above. • Response: ◦ 202 Updated ◦ The updated note. 75
  • 76. Delete a note: • Request URI: DELETE /api/note/<note-id> • Request body: <empty> • Response: ◦ 204 Removed ◦ <empty> Tags API Resource representation: { 'tag': '<string>', } GET all the tags: • Request URI: GET /api/tag/ • Response: ◦ 200 OK ◦ List of tags GET a tag: • Request URI: GET /api/tag/<tag-id> • Response: ◦ 200 OK ◦ The requested tag. CREATE a tag: • Request URI: POST /api/tag/ • Request body: JSON in the form of resource representation as defined above. • Response: ◦ 201 Created 76
  • 77. ◦ The tag that was created. EDIT a tag: • Request URI: PUT /api/tag/<note-id> • Request body: JSON in the form of resource representation as defined above. • Response: ◦ 202 Updated ◦ The updated tag. Delete a tag: • Request URI: DELETE /api/tag/<tag-id> • Request body: <empty> • Response: ◦ 204 Removed ◦ <empty> Search API The Search API allows developers to perform a full-text search through existing notes and return a list of appropriate Notes. Usage: • Request URI: GET /api/search?q=<urlencoded-query-terms> • Response: ◦ 200 OK ◦ List of valid notes resources. 77
  • 78. BRIEF RESUME Name : Aahana Tomar Enrollment Number : 9503954 Email ID: : aahana142@gmail.com Mobile Number : 9958053292 Significant Technical Achievements Hospital Management System (Mini Project in Database Management) An application comprising a database (MySQL) and a user-interface (HTML, CSS, PHP) for managing day-to-day functioning of small nursing homes. Scalable Storage System (Minor Project in Operating Systems) A scalable storage platform developed to allow building of reliable and scalable storage systems to provide users on a network space to store their personal files securely. The project was developed using Bash scripting and PHP. Imbroglio (Minor Project in Multimedia Development) A short animated movie to represent the contemporary social and political system of the country. The movie was developed using Adobe Flash and the designing was done using Adobe Photoshop and Adobe Illustrator. Significant Co-Curricular Kriti Magazine, Co-Editor Responsible for editing the content of college's bi-annual magazine Kriti. Summer Internship Completed my summer internship at HashStash Studio where I worked with the development team on Trivial Analytics, a minimal game analytics system for collecting data about user behavior. 78
  • 79. BRIEF RESUME Name : Vaidik Kapoor Enrollment Number : 9103471 Email ID: : kapoor.vaidik@gmail.com Mobile Number : 8860679256 Significant Technical Achievements Team Task Management Tool (Minor Project in Web Development) A web application to allow teams to effectively manage tasks divided various team members. Auto Text Generation (Minor Project in Compiler Design) An algorithm to automatically generate paragraphs for a given topic by implementing N-Gram model of speech and using a corpus populated from different repositories. Google Apps Integration with Drupal (Google Summer of Code 2011) Modules to provide various points of integration with the Google Apps service in Drupal, an open- source Content Management System (CMS). Password Protect (Mini Project in Algorithm Design) A Firefox add-on that helps a user with keeping her different accounts safe by generating different passwords for each account. The user has to remember just one password to access all of them. Summer Internship Completed my summer internship at Wingify Software Pvt. Ltd. where I worked with their development team on a RESTful API for their flagship product, Visual Website Optimizer. Later, I also designed and developed the architecture for Cross Browser A/B Test Validation system for Visual Website Optimizer. 79