lab 2 journalhub product specification outline purple team ...cpi/old/411/purpls16/... · the...

Lab 2 – JournalHub Product Specification Outline

Purple Team

Jason Mayo

CS411W

Professor Janet Brunelle

April 15, 2016

Version 1.0

Lab 2 – JournalHub Product Specification Outline 2

Table of Contents

1 Introduction..............................................................................................................................3

1.1 Purpose .........................................................................................................................4

1.2 Scope ............................................................................................................................5

1.3 Definitions, Acronyms, Abbreviations ..........................................................................7

1.4 References ....................................................................................................................8

1.5 Overview ......................................................................................................................8

2 General Description..................................................................................................................8

2.1 Prototype Architecture Description .................................................................................. 10

2.2 Prototype Functional Description ..................................................................................... 12

List of Figures

Figure 1. Current Process Flow: Story Development ...................................................................5

Figure 2. Improved Process Flow: Story Development ................................................................6

Figure 3. JournalHub Prototype Major Components .................................................................. 12

List of Tables

Table 1. Feature Comparison between Real World Product and Prototype ................................. 10


1 Introduction

The digital audience engaged with newspaper content has reached a new peak (Newspaper,

2015). The newspaper digital audience is growing more than twice as fast as the overall internet

audience (Newspaper, 2015), indicating a shift in the landscape of news media. With increased

demand for newspaper digital content, it is increasingly important for newsroom staff to remain

coordinated with one another. This coordination can be challenging to achieve when newsroom

staff number in the hundreds can be dispersed across the world, and newspapers are not the only

organizations facing this challenge. 35% of businesses indicating that a lack of a central source of

project management is the single greatest project management challenge (Burger, 2014). “[Staff

members] need an easy-to-use and efficient way to figure out what stories are running, where

they’re running, and when they’ll be running and… need to be able to access it from anywhere”

(E. Smith, personal communication, September 2015).

There exist software solutions to help coordinate staff members, but these programs lack

certain industry-specific features that would make them more complete. In particular, many of

these programs lack an adequate system to manage the budget, or the allocation of space within

the physical newspaper or the posting schedule for digital content. Other such programs lack a

budgeting system entirely. Another frequently missing feature is the ability to search for old

content. The ability to find relevant information from previous stories can bolster the quality of a

new story significantly. Providing a time-efficient way to find this information can help ensure

that higher quality stories are written more quickly than they would have been had this capability

not been available.


1.1 Purpose

The JournalHub systen, written by the Old Dominion University (ODU) CS411 Purple Team

is being developed to address the issue of coordinating the modern, disparate newsroom and to

make the task of finding relevant information from past stories more efficient.

One functional goal of the JournalHub prototype is to enhance the level of coordination with

which the newsroom staff operates. With the sheer volume of content in development at one time,

the centralization of story status information, deliverables, and deadline information for each story,

spanning all sections of the paper will significantly reduce the amount of effort it takes for editors

to monitor any one story. Furthermore, JournalHub will allow users to subscribe to email

notifications for a story. Whenever a change is made to the story, such as the completion status of

a task, a change to a deadline, or a change to staff assignments, subscribers will receive a

notification email detailing the change. This will help ensure that all members of staff working on

a particular story will be kept up-to-date on any changes that are made.

The second functional objective of the JournalHub prototype is to enhance the ability of

newsroom staff to generate quality articles. This is accomplished by organizing content using

hashtags and keeping track of event reminders. Hashtags will allow newsroom staff to quickly and

easily find relevant content from past articles for use in new ones by organizing past content and

making it easily accessible. Event reminders will have associations with a hashtag. This will be

useful to server as a reminder for newspaper staff about various events that could provide material

for a quality article. For example, checking on the status of a highway project, one year after a

story about its inception could potentially lead to a story on misappropriation of project funds.

Similar to stories, users can subscribe to an event to be notified when it is upcoming.


1.2 Scope

JournalHub is designed to be used primarily by modern news media organizations which deal

in both physical publications and online content. As such, it is built with the story development

process in mind and will be most useful to organizations such as these.

The project which became JournalHub was originally proposed by Ms. Erica Smith, Digital

News Editor for The Virginian-Pilot. As an editor, Ms. Smith is intimately familiar with the inner

workings of a modern newsroom. She identified centralization and accessibility of story

information as well as ability to efficiently locate relevant information from past stories as two

major impediments for her organization (E. Smith, personal communication, September 2015).

Figure 1 details the lack of centralization of story information as well as the inconsistency in

practices between the teams for different newspaper sections. Between sections, newspaper staff

employ widely varying software from traditional Content Management Systems (CMS) to Google

Docs. With no centralized repository of information, management of these different sections can

become tedious as each system must be accessed separately, especially when hundreds of stories

are in development at once.

Figure 1. Current Process Flow: Story Development


To solve the problem, Ms. Smith proposed to ODU’s Computer Science senior

undergraduates an enhanced CMS with support for the budgeting process that will make all story

and budget information accessible within a single interface. This includes both stories currently in

development and past stories. Figure 2 demonstrates the new process model, improved by

JournalHub.

Figure 2. Improved Process Flow: Story Development

All story information is condensed into a single page from which the editors or any other

member of staff can discern the current development status, budget information, and assigned staff

for the story. Similarly, an editor or any other authorized user may make changes to the budget

information for a particular newspaper from within one page, using a simple and intuitive drag-

and-drop interface. Ms. Smith agreed that the improvements brought by JournalHub would

significantly mitigate the coordination and information accessibility issues to a great extent (E.

Smith, personal communication, December 2015).


1.3 Definitions, Acronyms, Abbreviations

Budget – The allocation of physical space within a newspaper publication or publishing schedule

for online

Content

CMS – Content Management System, any system which organizes electronic documents

Edition – A version of a publication. Typically used when the distribution radius of a newspaper

is so wide

that stories can develop significantly while the paper is being distributed so that papers

distributed later can have more up-to-date information.

Event – A date of importance that requires future follow-up for a potential story

MySQL – An open-source, multi-user, relational database management system based on

Structured Query

Language (SQL)

ODU – Old Dominion University

PHP – A server-side programming language designed for building dynamic web pages

Project Management Software – Software which is designed to make easier the management of

personnel and information pertaining to a project or multiple projects

Publication – A single issue of a newspaper or other physical body of news media content

Slug – The pre-title name used to reference a story during the development process in the field of

Journalism

Story – A piece of news media content

VPS – Virtual Private Server


Web-based – Accessible via a web browser and is not required to be downloaded and installed

Zoning – The process of designating pages or areas of pages in a Publication for locality-specific

advertisements or other content. For example, different advertisements might appear on the

same page for a paper delivered to the northern part of a city as opposed to the southern part.

1.4 References

Newspaper Association of America (August 2015). NEWSPAPER DIGITAL AUDIENCE GREW

TWICE AS FAST AS THE INTERNET IN PAST 12 MONTHS. Retrieved from

http://www.naa.org/Trends-and-Numbers/Newspaper-Websites/Newspaper-Web-

Audience.aspx.

Burger, R. (2014, July 7). 14 Surprising Project Management Statistics. Retrieved from

http://blog.capterra.com/surprising-project-management-statistics

1.5 Overview

This product specification provides a high-level look at the goals and structure of the

JournalHub prototype. It established the purpose of the project and a brief descrioption about how

JournalHub achieves that purpose. This specification also describes the architecture and design of

the prototype and how the functional capabilities of JournalHub are achieved by this design.

Finally, the specification provides a precise list of requirements which the prototype must satisfy.

2 General Description

JournalHub is a web-based software system through which members of newsroom staff

can collaborate on story development and editors can manage budget information. At the user

level, JournalHub is comprised of three modules: a budgeting tool, for use by editors to manage

changes to the budget; an event manager, which allows staff members to subscribe to reminders


for events; and a story information section, which centralizes all information pertaining to a story

and allows users to subscribe to email notifications regarding changes to this information.

(This space intentionally left blank.)


2.1 Prototype Architecture Description

The JournalHub prototype will have structure and features similar to that of the real-world

product. Table 1 shows a direct comparison between the two. The major differences are the

omissions of integration of the pre-JournalHub database, social integration, and the mobile apps

in the prototype. Additionally, the budgeting system will have reduced functionality in the

prototype. Specifically, support for zoning of pages and editions will not be supported.

Table 1. Feature Comparison between Real World Product and Prototype

The website will be hosted on an InMotion Hosting (IMH) Virtual Private Server (VPS).

The JournalHub database will reside on the same server. The JournalHub prototype will be tested


by accessing the website directly from another machine. Additionally, the prototype will be

populated with story data that is devised for the purposes of testing.

The JournalHub database will take the form of a relational database using MySQL.

Infromation pertaining to user accounts, user types, stories, events, and publications will be written

directly to the database. The database will serve as a repository for this information and will be

queried whenever this information is needed by some procedure. The database will also be queried

whenever a user initiates a search procedure to find an event, publication, or story within the

system. These procedures will be written in PHP.

The website front-end will be written in HTML, PHP, and JavaScript. It will present a

tabbed interface that will display different functions of the website accessible to that user as

defined by the permissions of that user’s type. Frequently this information will be displayed in list

form. The website backend will be comprised of a series of SQL queries and updates embedded in

PHP. These queries will populate the lists and table views provided by the front end. The

JournalHub prototype will use Feng Office as a basis for the CMS portion of the prototype. Figure

3 illustrates the architecture of the JournalHub prototype.


Figure 3. JournalHub Prototype Major Components

2.2 Prototype Functional Description

When users attempts to visit a JournalHub page, the PHP back-end will verify the user’s

identity. If the user is not already logged in, the user will be prompted to do so. Once a user has

been logged in, they will be directed to the home screen from which they can navigate to the pages

for any of the major functionality provided for which their user type has access permissions. The

Publications page will display a list of Publications and allow the user to access the budgeting

system. This system will allow the user to easily manipulate budget information using a mobile-

friendly drag-and-drop interface. From this page, the user can add a Story to the current

Publication, remove a story, or move a story to a different Publication. Clicking on a Story will

take the user to that Story’s page.


The Stories page will display a list of stories to which that user has subscribed. It will also

allow the user to search for and subscribe to Stories. Clicking on a story in the list will take the

user to that Story’s page. A Story page contains all of the budget information associated with a

story as well as the slug, description, and Task list for the Story. The user will also be able to see

a change log for any changes made to the budget information or Task information for this story

such as the addition of Tasks, removal of Tasks, or changes to Task deadlines or staff assignments.

The user will also be able to subscribe to or unsubscribe from email notifications regarding these

changes. Clicking on one of these pieces of Task information will allow the user to modify it by

writing to the database.

The Events page will display a list of events to which the user is subscribed. It will display

the title of the event, a brief description, the timestamp, and the hashtags associated with the Event.

The user will also be able to search for and subscribe to events from this page. Clicking on an

event in the list will take the user to the Event page. This page will allow the user to edit the event

information such as the name, timestamp, and hashtags.

The settings page will allow the user to make changes to their own account such as setting

a new password and contact email for the purposes of notifications. The Administrator page will

allow the user to make these changes for all other accounts. The user will also be able to add or

modify user types by granting or removing access permissions for the various functionalities in

the JournalHub system.

lab 2 journalhub product specification outline purple team ...cpi/old/411/purpls16/... · the...

Documents