1
Lab II - EmVi Product Specification
EmVi – Orange Team
David Wise
CS411W
Mrs. Brunelle
July 26, 2016
Version 1.0
Lab II – EmVi Product Description
2
Table of Contents
1.
2.
3.
Introduction ............................................................................................................................ 3
1.1. Purpose........................................................................................................................... 3
1.2. Scope .............................................................................................................................. 5
1.3. Definitions, Acronyms, and Abbreviations ................................................................... 7
1.4. References .................................................................................................................... 11
1.5. Overview ...................................................................................................................... 12
General Description ............................................................................................................. 12
2.1. Prototype Architecture Description ............................................................................. 13
2.2. Prototype Functional Description ................................................................................ 17
2.3. Extended Interfaces ...................................................................................................... 21
Spacific Requirements ......................................................................................................... 22
List of Figures
Figure 1 Current Marketing Email Generation Proccess .............................................................................. 6
Figure 2 Proposed Marketing Email Generation Process ............................................................................. 7
Figure 3 EmVi User Interface Site Map ..................................................................................................... 13
Figure 4 Prototype Major functional Component Diagram ........................................................................ 14
Figure 5 EmVi Database Schema ............................................................................................................... 15
Figure 6 User Log on Page Test Script ....................................................................................................... 21
Lab II – EmVi Product Description
3
1. Introduction
Email is an active tool in the marketing industry. The use of email in marketing dates back
to the early 90’s. During its early days email was used to send unsolicited bulk messages, more
commonly known as “SPAM”. Things have changed quite a bit since then. Even in today’s new
world of mobile devices and social media networks, email still reigns as the dominant method for
advertising and marketing.
Two thirds of all email users check their email on average three times a day (Connolly,
2011). This means that the email content is being viewed by potential customers. In a report
from SOS Emarketing, ROI Comparison Across Media Channels, email marketing generates, on
average, about $40 for every dollar invested (Schwartz, 2011).
Because of this, 97% of
companies said that they would be increasing their email marketing budgets (Rice, 2012).
The process of creating email content across various clients is time consuming. The email
has to be created and then sent through a rigorous approval process that can “trap” that content in
an endless loop of disapprovals and rework. The goal of this approval process is to ensure that
accurate representation of the company and its products is displayed in the marketing email that
is delivered. Mistakes are costly and embarrassing so this approval is an essential step.
Along with the process being time consuming, testing to make sure it renders correctly can
be complicated. Keeping track of changes in the client software is a full time job when you are
talking about hundreds of different options. This is accomplished through the time consuming
task of sending out the content and checking to see if it looks right at the receiving end and then
approving or rejecting. If the email is rejected then the process has to begin again and all effort
toward delivery is lost.
Lab II – EmVi Product Description
4
1.1. Purpose
EmVi – Email Viewer (Email Content Management System) is a solution provided by the
Old Dominion University (ODU) CS411 Orange Group designed to reduce the time and
complexity of generating and approving marketing email. The solution will be a stand-alone
email content management system with the capability of being integrated into an existing email
marketing system. The process of getting approvals will be streamlined in a way as to break the
endless approval loops that can send an email campaign task beyond deadlines. There will be
fast reliable testing of the email content where results can be provided to those generating the
campaigns to reduce the errors the first time. If the content generation team were to have the
capability to view a submitted marketing email before it moves on to the approval stages, it
would provide an opportunity to proof the content in advance, reducing the number of times a
campaign would be rejected. This would reduce the time from concept to delivery for marketing
email.
EmVi provides a global solution for email marketing content management, testing and
campaign distribution. The overall effort in this project is to provide a tool that will seamlessly
integrate into the current standard operating procedure of any email marketing agency allowing
for a more streamlined approach to their marketing strategy. This tool will store the content,
making it available to other projects and campaigns through a content management system
(CMS). It will provide an interface through which testing can be performed at any stage in the
development of the campaign. EmVi will create an environment from which a streamlined
approval and distribution process can take place, reducing the time and complexity currently
involved in performing the task of creating and approving marketing email.
Lab II – EmVi Product Description
5
1.2. Scope
EmVi will be a stand-alone system to be used on a single workstation or run on a server to
be used in a larger organization with multiple entities needing access. EmVi will have the ability
to interface with other tools such as CMS or Content Delivery Network (CDN) through the use
of application programming interfaces (API). The tool will also provide a What You See Is
What You Get (WYSIWYG) editor to allow the content to be modified at different stages of
approval.
EmVi will provide an interface where campaign content can be uploaded quickly and stored
on the local system in a stand-alone environment or on a server in the larger installation. After
the content has been uploaded it can be viewed in various web browsers and email clients
through the automated retrieval of images from test browsers and clients. This will give an
accurate set of images from which an approver can verify the content is correct and visually
appealing.
EmVi will allow all email campaign marketing tasks to take place in house generating the
end product in less time. It will provide tools to allow the team generating the content to see it in
real browsers and clients, allowing them to critique their own work prior to sending it off for
approval and thus decreasing the amount of little errors that delay the distribution of marketing
email. Decreasing the amount of time from inception to delivery of a marketing email will
reduce the cost of developing the campaign, increasing the return on investment.
The goal of EmVi is to streamline the email testing process to enable rapid iteration on
designs allowing for a quicker approval of email campaigns to be distributed. The objective in
creating EmVi is to automate much of the current process outlined in Figure 1. As described
earlier, this process is very time consuming and some of the finer details that will be discussed
Lab II – EmVi Product Description
6
later are complex. This current process has a flaw in that some of the steps are handled by
outside agencies causing delays in the testing and approval phases when working a campaign
through the process. With EmVi, the aim is to automate some of these steps and bring others
back into the control of the local teams. Figure 2 outlines where EmVi will reduce the current
process, thus reducing the timeline required to generate and distribute content.
Figure 1 Current Marketing Email Generation Proccess
In Figure 2, the tasks of uploading and testing are moved back into the creative team’s
hands. The whole process stays in house and can be accomplished without the reliance of
another organization or group. With EmVi the aim is to provide an interface to upload content
and automate the distribution of test emails, generation of preview images, the approval process
and version control for campaigns.
Lab II – EmVi Product Description
Figure 2 Proposed Marketing Email Generation Process
(This space intentionally left blank.)
1.3. Definitions, Acronyms, and Abbreviations
7
Lab II – EmVi Product Description
8
Access Control: Security features that control who can access resources in the operating system,
selective restriction.
Administrator (Admin): Has the ability to create and remove new contributors as well as restrict
their access.
Analytics: The process of transforming data into meaningful patterns to help in the decision
making process.
API: Application Programming Interface
Approval Chain: The series of steps necessary for an email to be authorized and distributed.
Approval Tracking: Specific to a workflow, the workflow action to perform when a user sets an
approval type.
Authentication: The process of identifying an individual, usually based on a username and
password.
Azure: A Content Distribution Network (CDN), a Microsoft product that allows you to build,
deploy, and manage applications globally.
Campaign Filter: Allows campaigns to display based on criteria that are chosen by the user.
Campaign Search: Searching for the content of a campaign (content browsing).
Content Distribution Network (CDN): Or delivery network is a large system of servers that
allows for faster and more efficient delivery of content to end-users.
Contributor: Has the ability to read, write, and edit content.
Customize: Changing or altering to fit current needs.
Database: A collection of information organized in a manner which allows for efficient retrieval.
Dynamic messaging: The use of variable content to fill particular sections of an email message.
Some examples are using first name personalization or product name insertions within
the body of a message.
Drupal: A Content Management System (CMS) that allows for easy organization, management,
and publishing of content, with an endless variety of customization.
ECMS: Email Content Management System
Email Campaign: A single instance of an email sent to a list of email addresses. Campaigns
may include multiple sends and multiple messages.
Email Client: A computer program used to access and manage a user’s email.
Lab II – EmVi Product Description
9
Email header: The data that appears in the header of an email message, usually consisting of to
and from email addresses, email subject and IP-level tracking information.
Email Marketing: Usually done by a company to directly market a commercial message for
promotional or notification purposes to a group of consumers through the use of email.
Email Message: A single email received to an email address within a campaign. A message
contains a multipart, alternative message which includes an HTML and text file.
ESP: Email Service Provider
Exact Target: A provider of data driven marketing solutions for email content creation, list
management, etc. This company is capable of integration with CDNs.
HTML Email: A subset of HTML that is not well defined and can sometimes have differing
results depending on the email client in which it is viewed in. Some email clients do not
support HTML email at all.
Integrative: Combining or unifying.
Litmus: A company that allows for the rendering and testing of email across various email
clients. Also, email analytics, spam filter tests, and page tests can be performed.
Metadata: Descriptive data about campaigns and images that can be used to search for content.
Multipart, Alternative: An email that includes both an HTML and text version. The email client
determines which version to display.
Open Source: Computer software made available publicly and free of charge.
Outsourcing: The contracting of internal business processes to a third party organization.
Permissions: Or rights, are characteristics given by users or network administrators that prevent
or allow access to files on a computer network.
RACI Chart: Responsible, Accountable, Consulted, Informed. This chart displays the various
roles and responsibilities required in completing tasks for a project or business process.
Simple Mail Transfer Protocol (SMTP): An internet protocol for sending and receiving email
messages.
Version Control: A system to record changes that are made to a campaign. This grants the
ability to restore the campaign to a previous version if necessary.
Web Application: An application that is accessed over the internet usually through a web
browser. This allows the application to be used on multiple platforms.
Lab II – EmVi Product Description
Web Server: The hardware or software that helps deliver web content and can be accessed
through the internet.
Workflow: A series of connected steps to complete a process.
(This space intentionally left blank.)
10
Lab II – EmVi Product Description
1.4. References
Balegno, S. (2011), Report: 2011 Email Marketing Benchmark Report, 2011.
Rice, J. (2012), Report: 2012 Email Marketing Benchmark Report, 6, 2012.
Schwartz, D. (2011), SOS Emarketing, ROI Comparison Across Media Channels. SOS
eMarketing, 15 Nov. 2011. Web. 9 October 2013.
Connolly, L. (2011), Report: View from the Digital Inbox 2011, 2011.
Radicati, S. (2012), Report: The Radicati Group Email Market, 2012-2016, 2012.
Lab1 – EmVi Product Description. Version 4. (2013, October). EmVi. Orange Team. CS411:
David Wise.
(This space intentionally left blank.)
11
Lab II – EmVi Product Description
12
1.5. Overview
This product specification will provide an introduction to the hardware, software
configuration and external interfaces required to provide the capabilities of the EmVi prototype.
The remaining sections of this document will describe in detail the hardware, software and
external interfaces that must be built into the EmVi prototype in order to meet the needs of the
customer. Included in the description of the prototype will be features and capabilities that will
be part of the EmVi prototype. The prototype will be a store and forward type of system and as
such, there will be features that will secure, control and manage how the data will be accessed
and moved through EmVi. These specific requirements will be defined in the following sections
on this document.
2. General Description
In an effort to provide a proof of concept the EmVi team will be building a prototype of
EmVi that will demonstrate the capabilities of the application without all of the complexity that
would be involved in a full scale build and configuration. Test campaigns and pre generated
images will be used to demonstrate the flow of data and approvals through EmVi. The EmVi
prototype will be an email content management system that will streamline the testing and
development process of campaigns. With this prototype, the plan is to show a reduction of errors
in email content, reduction in cost associated with processing an email campaign and get those
campaigns to production and to the customers in a quicker more reliable manner.
The EmVi prototype will provide a GUI written in HTML, PHP and JavaScript containing
various user role interfaces such as administrator, campaign administrator, contributor, and
approver. Each of these roles will have different capabilities within the tool derived from flags
set in the database. Some of these roles can be seen in the site map in Figure 3. The prototype
Lab II – EmVi Product Description
13
will demonstrate the functionality of the registration and logon pages. After a user registers for
access to the prototype it will demonstrate the capability to deliver confirmation email via the
send mail function provided in PHP. The backbone of the EmVi tool will be the MySQL
database. The EmVi team will demonstrate the ability to interface with database in order to save
new data, update records and remove data. This will provide a demonstration of the access
control measures and version control for both EmVi versioning and Campaigns. This tool will
automate the distribution of test emails which currently, is a manual process. After these test
emails are sent the EmVi prototype will render and retrieve the rendered marketing email images
to be used in the approval process.
Figure 3 EmVi User Interface Site Map
2.1. Prototype Architecture Description
Figure 4 provides a visual representation of the prototype components. The prototype
will simulate parts of the application in order to provide services that would normally already be
Lab II – EmVi Product Description
14
onsite or need to be purchased such as a CDN account. This diagram will be described in further
detail later.
Simulated CDN file
share
Web
Browser
Email Designer
EmVi Web Application
Running on a virtual
machine on CS ODU
network
File System
Version
Controlled
Simulated Email Simulated Email Simulated Email
previews for view previews for view previews for view
SMTP Server Running in
a virtual environment
On ODU CS network
My SQL
Database Running on
ODU CS Network
Simulated Data containing test
campaigns with links to
simulated CDN and Previews.
Figure 4 Prototype Major functional Component Diagram
In the prototype, the server will be a virtual computer running Linux operating system
located on the computer science network at Old Dominion University. The development and test
team will utilize this virtual computer to run the web application, the database, and the SMTP
services needed to test email campaigns. The development environment will be the EmVi
team’s personal computers and or the ODU CS lab.
Much of the development can be
accomplished with the typical text editor like notepad. The development team will be using
some integrated development environments (IDE) such as Microsoft Expressions, Eclipse, and
Notepad++ to program the HTML and PHP required to generate the GUI. The CS350 git system
will provide a way to handle the versioning and the multiple programmer environments.
Lab II – EmVi Product Description
15
The prototype will simulate access to the CDN and Test rendering environment via an
API to a file server containing the files that will be stored in the database as a URL. A
demonstration of the functionality of EmVi will be accomplished with the use of the open source
MySQL database engine.
This is a fairly powerful database engine for smaller projects that
require database support. MySQL databases can be easily ported over to other larger database
engines such as Microsoft SQL and Oracle. MySQL will be used because it is free and will
work in small scale implementations of EmVi. Figure 5 provides a high level representation of
the database schema that is planned to be implemented for EmVi. It will hold the access control
parameters as well as build the structure needed to generate an approval flow through the system
and maintain data needed to generate the test email.
Figure 5 EmVi Database Schema
The EmVi development team will be building a custom framework on which to build the
rest of EmVi. It will be a structured MVC environment separating the logic from the visual
presentation to the end user. This will allow the tool to process in the back end while still
engaging the end user of the application. Play framework was considered as an initial starting
Lab II – EmVi Product Description
16
point but after looking into that found that the learning curve would be greater than just building
one from scratch. The MVC will be built using the PHP scripting language.
The prototype for EmVi in the web server software will not differ too much from what the real
application will provide. The Linux, Apache, MySQL, and PHP (LAMP) configuration will be
used to accomplish this. The difference will be in some of the scripting and API programming.
EmVi will deploy a User based access control system. Users will register with the site
and wait for an EmVi administrator’s approval before being allowed to log in. The EmVi
administrator will set the permissions for the end user based on the request and the role that user
plays in the campaign lifecycle. Access rights will be stored and managed in the database and
maintained via an administration page in the web application shown in Figure 3.
The development team will provide an API for EmVi to allow for seamless integration
into other systems. This will be publically available. This API will provide an interface from
which other developers can incorporate this tool into their environment. It will provide a list of
programming functions that will pass instructions into the EmVi environment.
The web page logic will not change drastically from what is proposed for a real world
product provided in Figure 3. The movement and PHP scripting will be the same and only the
API’s that determine where the data comes from will change in a real world implementation of
the tool. Testing functionality will need to be added to the prototype in order to fully test and get
automated feedback from the system.
This will not change the logic just provide more
information to the development team.
The interface with the MySQL database will be accomplished via the MySQL API
provided with PHP. The database will be prepopulated with test data to run a campaign from
inception to closure. The EmVi prototype will have existing campaigns in various stages of
Lab II – EmVi Product Description
17
completion and approvals to test every avenue of the system. The data that will be stored as part
of the prototype will be like data used in production so that a true representation of the tool can
be acquired.
EmVi will utilize a real SMTP server to generate email for both registration and email test
sends. These emails will then have to be parsed to generate images that the approvers will
review to allow them to make informed decisions to advance a campaign. EmVi will use the
sendmail application that can be setup on Linux and the PHP API mail, to send out the
notification and test email.
2.2. Prototype Functional Description
In the prototype, EmVi will simulate some of the features and capabilities that would be
programmed in the real world application. Some of the areas that will be simulated will be the
API to CDN and the email rendering environment. If the EmVi team has the bandwidth to add
these in as a non-simulated feature, then that will take place toward the end of the semester.
Some of the major features include authentication, storage of campaign data, the approval
workflow, and the email send-to test distribution. These will all be provided in the prototype of
EmVi either as a functioning part of the application or a simulation to assist in demonstration the
capabilities.
Authentication will be handled by the database and PHP scripts at a logon page. After a user
registers for access to the tool the EmVi administrator can then approve the registered user and
set that user’s roles in the system. Once this is complete, the user will be able to browse to the
EmVi logon page and present their credentials for authentication. If they are successfully
entered, the user will be granted access to the EmVi tool with the user access roles defined in
their account. At successful authentication, a cookie will also be issued for managing the current
Lab II – EmVi Product Description
18
session for the user and provide some security as the user moves through the site and the data
stored within the database.
The determination of what will be stored and how to store it is the first thing that needs to be
accomplished to make all of the parts of EmVi work as one fluent system. With a campaign,
there will be HTML, plain text and image files that will need to be stored. The plan is to store
the HTML and text files as long strings in the database and the image files on a simulated CDN.
The prototype will have the ability to interpret, parse and insert into the database or unpack files
and copy them to the file shares in the case of images. A file server will be used to simulate the
CDN, so there will be a URL pointing to the image that can be used when generating the
campaign email on send.
The workflow will not be simulated. Test users will be generated in the EmVi prototype to
allow the movement of a campaign from inception to final product through the system. This will
provide a workflow demonstration of the tool with each user role acting on the campaign in its
turn.
When a new campaign is generated, it is attached to an automatic test distribution list. The
campaign administrators (those creating the campaign instance) will have the option to add
additional email addresses to the campaign for sending to their own test accounts outside of the
tool. The send-to distribution will be an automated aspect of the tool and will be used to
generate the images of the campaigns in the different browsers and clients.
With any tool there needs to be a division of labor. The EmVi tool will separate the roles
into four major sections; campaign administrators, contributor, approver, and administrators.
Each of these groups will play different key parts in the tool and workflow.
Lab II – EmVi Product Description
19
Campaign Administrators will kick off the campaign and workflow. They are the catalyst for
this process. An administrator can generate a new empty campaign or kick off a new one from a
copy of an existing campaign that they already have access to.
Contributors will be able to edit the campaigns that they have access to allowing them to add
and remove content from the campaign. They will be able to copy content between campaigns
that they own and can set campaigns as ready for testing and approval. They will be able to
upload content to the campaign such as HTML and text files as well as content to display the
HTML properly such as photos.
An approver will be able to do all the contributor tasks as well as approve campaigns created
by any contributor. They will be able to reject active campaigns awaiting approval to send back
to the contributor for further editing. As an approver, they will be able to set the status of a
campaign based on their analysis of the tests. With the approver having the same capabilities as
a creator, a system of checks and balances needs to be in place, so an approver cannot approve a
campaign that is generated by self.
Administrators will be able to do all tasks that all of the other user types can do with the
addition of account maintenance and EmVi system configuration. Administrators will have the
ability to assign and remove contributor as owners of campaigns. Administrators can modify
access rights to campaigns assigning contributors and approvers to the campaign workflow that
they currently do not belong to. They can edit the status of campaigns. One of the major roles of
an administrator is access control. They will be responsible for the addition, approval and
modification of user accounts on the system.
Lab II – EmVi Product Description
20
Registration will be required in order to use this system. The data being housed could
potentially be proprietary in nature and needs to be protected and separated by a need to know
environment. There will be a registration page in the GUI with a link from the home logon page.
After a potential user registers for access, they will still be unable to log into the system until
they have been verified by an administrator who will, as described as part of their roll, approve
or reject the request for access. The user will receive an email that will be sent using the PHP
send mail function and the SMTP server. This email will contain information about the user’s
registration and the steps that the user can expect to happen next. After successful registration
and activation, the user will be able to log into the EmVi tool via a logon page that will generate
session information. They will be able to use the system as long as the session is active. The
session will have an inactive timer that will auto log out after a set amount of time. When the
user logs off or closes the browser, their session will be destroyed to prevent unauthorized
access.
The tool home page will be the logon page. The user will present their credentials to the tool.
If the credentials provided match what is stored in the database fir that user, they will be granted
access to the site. If not then they will receive a message stating that the account does not exist
and request that registration take place, that the account is not active, or that improper credentials
were provided. Once logged in the user roles kick in to allow them to perform their assigned
actions in the tool.
The ability to preview test email is an important aspect of this tool. The email preview will
allow the final inspection of an email campaign and the grounds for approval or rejection of a
campaign. After a campaign is sent to the test distribution list, a compilation of the images will
be provided that represent how the campaign email will look in different HTML browsers and
Lab II – EmVi Product Description
21
email clients to ensure that no mistakes were made and that it renders correctly for proper
viewing at the customer end of the chain.
These will be presented as thumbnails to the
contributors and approvers in the EmVi tool, where they will have the ability to sample as many
as is needed to verify correctness of the campaign before sending out to customer distribution.
The EmVi team along with the case study group will run through the features defined in this
prototype description. Test scripts will be used to verify the functionality of the GUI. This will
ensure that it is working and looks correct. Figure 6 is an example of the script that would be
used to test the user logon page.
Figure 6 User Log on Page Test Script
2.3. External Interfaces
External interfaces will be limited to standard computer hardware and software. EmVi will
provide a set of custom interfaces for the user, CDN, and email previews.
2.3.1. Hardware Interfaces
No hardware interfaces will be built for EmVi. The prototype will be accessible via an ODU
classroom or lab computer or an orange group member’s computer. The website for EmVi will
be hosted on the ODU CS department server and network.
Lab II – EmVi Product Description
22
2.3.2. Software interfaces
The group will interface with the MySQL database via a web interface tool called
PHPMyAdmin. The PHP and HTML pages will be created using standard text editors and IDEs.
There will also be a SMPT interface to allow for system notifications and sending campaigns to
test. Newly created pages will be uploaded to the production server via an FTP client of the
developer’s choice.
2.3.3. User Interfaces
The main user interface will be accessible via any internet-connected personal computer with
a web browser. The initial interface will be the logon page. The web site map is provided in
figure 3. This will be the only interface an EmVi user will have. As an EmVi administrator
there will be other user interfaces for CDN configuration and email preview configuration.
2.3.4. Communication Protocols and interfaces
Standard TCP/IP and UDP protocols will be used to interface with EmVi. No new protocol
or ports are required to access EmVi.
3. Specific Requirements
(Section three was provided as a separate deliverable)