doc

shoulderscobblerInternet and Web Development

Feb 2, 2013 (4 years and 9 months ago)

198 views

Taj Campbell, Dana Fujimoto, Brian Steadman Page
1

rail
pad


1
Operational Concepts


1.1
Statement of Purpose


1.1.1
Problem


In the world of text editing,

most

software systems fall short of the
requirements of everyday users in terms of
usability
,
collaborative ability,
accessibility,

extensibility and af
fordability. For many
current software systems, achieving any of
these
factors often means sacrifices in other
areas. While Microsoft Word might be great
for tracking changes and adding comments,
it is difficult to create a central repository
where the doc
ument can be saved, and each
user must own an expensive software
license. Similarly, while Mediawiki is open
-
source, free of charge and accessible
through a web browser, pages for editing
and discussion about content are separate
from the document, and tra
cking changes
through revisions can be difficult.


In short, there is a space for a web
-
based application that is good at many of the
aforementioned factors: a complete software
system that is open
-
source and freely
available, with the look and feel of a n
ormal
application like Microsoft Word and the
accessibility of a Mediawiki site.


1.1.2
Proposed Solution


We propose to create a web
-
based
application for collaborative text editing. To
eliminate costs and for both developers and
users, the system will be

entirely open
source in terms of new and existing code
and services.


The system will consist of a web
-
server running our software, which will be
accessible through most modern web
browsers. Through a unique user interface,
the user can create new documen
ts and
specify a list of other users who can edit and
comment upon those documents. As
documents are edited, past revisions are
saved and easy to access again.
Within the
editing pane are tools for word formatting
and spell checking.
Policies can be set fo
r
user permissions to edit and comment.
Documents can be printed and exported for
use elsewhere. Most important, because the
software will be open
-
source, it can be
publicly released to a community that will
continue to maintain it and it will be
extensibl
e for other developers to add
features they need.


1.2
Project Objectives and
Scope


1.2.1 User Community


Authors who need cross
-
platform
accessibility and the ability to collaborate
with other authors on a text document.



1.2.2 Program Environment


Any
personal computer with access
to the Internet and a modern web browser.


1.2.3 Major Benefits


Essentially, this project is a major
facelift for the Wiki model
, which offers an
accessible, collaborative text editor that can
be used through most web browser
s
. The
major improvement is a
user interface
that is

much more intuitive
and a look and f
eel

that
is much closer to a normal software
Taj Campbell, Dana Fujimoto, Brian Steadman Page
2

application. This will provide a powerful
environment for groups to co
-
author papers
and track changes without the need fo
r more
complex or expensive software tools.


1.2.4

System Capabilities



Create document



View document in print mode



View document in outline mode



Add/remove/merge
sections



View document in edit mode



Edit and format
sections



Page through section revisions



Vi
ew/hide section changes (deletions
crossed out, additions highlighted)



View/hide change comment



View/hide section comments panel



Add and page through comments



View/hide menu



Change document preferences



Change/add/remove
authors/commenters



Export document t
o text file



Cross browser compatibility


1.2.5

System Limitations



Not ideal for a large number of
authors/commenters



No fancy formatting



No import feature



No system installer (though
directions for installation will be
provided)



No editing multiple
section
s

simultaneously



No file repository for uploading
images/attachments


1.3
Project Vision


The
sample

illustrations
at the end of
this document outline
some ideas for the
user interface and system functionality.



2
System Requirements


2.1
Hardware Require
ments


2.1.1 Client


Any personal computer with internet
access.


2.1.2 Server


A moderately fast x86 server that can
handle heavy traffic and database queries.


2.2
Software Requirements


2.2.1 Client


Windows XP, Mac OS X and a
Linux
distribution

for OS
trials. Each OS
should have a number of web browsers for
testing, but our focus will be compatibility
with the latest versions of Internet Explorer,
Firefox and Opera.


2.2.2 Server


Some variation of Linux with
Apache, FastCGI, MySQL, Ruby and Rails.




3

System and Software
Architecture


3.1
System Structure


The structure of the system is pretty
straightforward. A limited number of users,
each from their own personal computer, can
Taj Campbell, Dana Fujimoto, Brian Steadman Page
3

use a web browser to access the service
provided by our product. Everythin
g in
Railpad is generated server
-
side and all
interaction between users and the Railpad
system is done through the web browser.




3.2
Software Components


The software parts behind Railpad
also fit together quite easily. Railpad is
written in Ruby with t
he Rails framework.
This code interacts with cascading style
sheets and a MySQL database to gather
everything for presentation to the user. Once
a user logs into the system, information
retrieval and storage requests are sent to the
server through the inte
rnet. Hypertext is then
transmitted across the internet to the user, or
changes made to the document are
transferred to the web server and placed in
the database for future retrieval.





4
Lifecycle Plan


4.1
Who

is
interested?


Anyone participating in
a

collaborative writing

project

(Editors,
Professors, Student
s, Journalists, Authors,
etc).
The finished product will be a simple,
easy to use and irreplaceable

aid in their
writing process.
It will especially save time
and heartache in terms of making a pi
ece of
writing accessible a
nd open to constant
revisions.
Under ideal circumstances, this
software sy
stem will be able to provide a
balance of freedom, creative control

and
constructive
feedback that will allow authors
and editors to quickly and efficientl
y
collaborate on writing projects. Also, its
extensibility will allow other software
developers to create new uses based on the
foundation we provide.



4.2
Who
is

supportive?


Internet users, especially writing,
academic and web development
comm
unities wi
th limited resources.

The

ease of use

and reliability

of this product
should minimize normal software related
headaches allowing writers and editors to
concentrate purely
on the writing process.
Additionally, by using an open source base
and providing our
own code freely, there is a
strong possibility it will be passed on to the
open source community for maintenance
and enhancement. Although open source
means our software will be freely and easily
obtained
,
donations from the user
community could drive furt
her development
in the future.


4.3 And the
stakeholders?


Initially, the most important
stakeholders are the developers. We need to
ensure we create a product that will make an
impact in this market segment. This will
Taj Campbell, Dana Fujimoto, Brian Steadman Page
4

help us to garner support for continu
ing
development and maintenance through a
new community after the course ends. Thus,
development must be focused on a stable,
extensible code base that pays close
attention to open source modeling and cross
-
platform compatibility. The second set of
major s
takeholders will be our users. They
will provide necessary feedback to improve
the product and make it worthwhile to
continue development in the future.


4
Feasibility Rationale


4.1
Cost Analysis


The cost of the project is the
involvement of 6
-
8 thoughtf
ul students over
an 8 week period. In this time, many of the
students will have to learn new development
environments to make this project a reality.
While software development will be the
largest factor in completing the project, it is
also important to g
ather 1 or 2 good
designers with an interest in user interfaces.
The time limit is short, but it will be possible
to finish if work is divided among the
students appropriately.


4.2
Scale Up



Detailed installation
instructions/tutorial with images



Extension

for adding project
calendar/milestones



Extension for adding new pages to
manage other aspects of the project



Expanding user registration system
for email notifications



Add feature to email link to
document



Extension to add files to a shared
repository


4.
3
Scale Down



Remove c
omments check off



Remove show difference between
revisions



Remove merge
sections



Limit use of fancy JavaScript


4.4
Risk Analysis


There is a large assumption that
Ruby on Rails and AJAX will provide an
effective framework to develop t
he product
in a way that the UI improvements will have
a huge impact over existing models. Should
expanding/collapsing menus and paging
through revisions and comments not work as
supposed, we might end up with a system
that is not too different from Writeb
oard or
MediaWiki. In this case, we have failed to
create an innovative product that is worth
developing in the future.


Additionally, there is an assumption
that new web development technologies
have an easy learning curve. Few of us will
likely come into

the project with a strong
understanding of Ruby on Rails, AJAX,
CSS, MySQL and PHP. All of these tools
will need to be understood to ma
ke our
product fully functional.















Taj Campbell, Dana Fujimoto, Brian Steadman Page
5

Illustration 1




Railpad places everything within reach, integrating u
ser feedback directly
into the editing page. Additionally, all of the tools stay at the author’s
fingertips in a simple, uncluttered manner. Clicking the Railpad icon reveals
a drop
-
down menu with additional viewing and login options. Comments on
the right

can be hidden to better utilize screen space.






Illustration 2




Clicking the edit button on a document section seamlessly overlays a simple
editing window. No new pages need to be loaded, reducing confusion from
moving between pages in the browser.