National Institute of Applied Science and Technology Graduation Project Design and Implementation of a Landing Page Builder

National Institute of Applied Science and Technology
CARTHAGE UNIVERSITY
Graduation Project
Course : Software Engineering
Design and Implementation of a Landing Page Builder
Performed By
Khalil Fadhel
Monitored By : Ms NORMAN Sophie
Supervised By : Ms AROUR Khedija
Defended On : 28/06/2016
JURY
President : Ms Narjes ROBBANA
Examiner : Ms Ghada GASMI
Academic Year : 2015/2016

Table Of Contents
List of Figures iv
List of Tables vi
Abstract vii
General Introduction 1
I Environment Analysis and Preliminary Study 2
General Introduction 2
1 Overview of the hosting company . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 The Software Development Methodology . . . . . . . . . . . . . . . . . . . . . . 3
4 State of Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Overview of existing solutions . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2.1 WYSIWYG Rich HTML Editors . . . . . . . . . . . . . . . . . 4
4.2.2 Web Content Management Systems . . . . . . . . . . . . . . . . 4
4.2.3 Web Page Development from Scratch . . . . . . . . . . . . . . . 5
4.2.4 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5 Project Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 Web 3.0 and Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
II Requirements Analysis and System Speciﬁcation 9
1 Template Layout Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Layout elements structure . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Actors Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 The Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 The Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
i

Remerciements
5 Use Case and Functional Requirements Modeling . . . . . . . . . . . . . . . . . 16
5.1 General Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Use Case: Create Landing Page . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Use Case:"Manage Landing Pages" . . . . . . . . . . . . . . . . . . . . . 21
5.4 Use Case:"Create Template" . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5 Use Case:"Manage Templates" . . . . . . . . . . . . . . . . . . . . . . . . 25
5.6 Use Case:"Manage Client Pages" . . . . . . . . . . . . . . . . . . . . . . . 25
5.7 Use Case:"Visualize Landing Page" . . . . . . . . . . . . . . . . . . . . . 25
5.8 Use Case:"Subscribe to NewsLetter" . . . . . . . . . . . . . . . . . . . . . 26
IIISystem Design and Architecture 27
1 Operational Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 Applicative Architecture : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Page Generation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Solutions Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Template Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Generated Page Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 General Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.2.1 Saving and Generating Behaviours . . . . . . . . . . . 39
4.1.2.2 Landing Page Behaviours . . . . . . . . . . . . . . . . 42
4.2 WYSIWYG Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Template Parsing and extracting layout elements . . . . . . . . 47
4.2.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 52
IV Technological Tools and Implementation 58
1 Hardware and Software Work environments . . . . . . . . . . . . . . . . . . . . 59
2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3 Human Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1 Admin Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2 Client Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ii

Table of Contents
Conclusion and perspectives 76
References 77
iii

List of Figures
I.1 Company Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
II.1 Template structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
II.2 Template layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
II.3 General Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.4 Use Case:Create Landing Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II.5 activity diagram : create landing page . . . . . . . . . . . . . . . . . . . . . . . 19
II.6 Use Case:Manage Landing Pages . . . . . . . . . . . . . . . . . . . . . . . . . . 21
II.7 use case : create template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
II.8 activity diagram : create template . . . . . . . . . . . . . . . . . . . . . . . . . . 23
II.9 use case : manage template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
III.1 Operational Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
III.2 Landing Page Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
III.3 MVC Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
III.4 Page Generation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
III.5 Comparative table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
III.6 static vs dynamic html time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
III.7 Template Layout and Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 35
III.8 semantic markups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
III.9 tracking tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
III.10class diagram : Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
III.11class diagram : Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
III.12class diagram : Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
III.13Sequence diagram : Landing Page Saving on server side . . . . . . . . . . . . . . 40
III.14Sequence diagram : Landing Page generating on server side . . . . . . . . . . . . 42
III.15Sequence diagram : Landing Page Mailing List Subscription . . . . . . . . . . . 43
III.16Sequence diagram : Landing Page Clicks and Views Tracking . . . . . . . . . . . 44
III.17WYSWYG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
III.18MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
III.19Template Parsing code example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
III.20Template Parsing code example2 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
III.21Content Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
iv

List of Figures
III.22Attribute Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
III.23Parameters recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
III.24Template Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
III.25Attribute element rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
III.26Content element rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
III.27Sequence diagram: Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
III.28Sequence diagram: Input Filling . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
III.29Sequence diagram: Client Side Save . . . . . . . . . . . . . . . . . . . . . . . . . 55
III.30Sequence diagram: Page Publish . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
IV.1 Deployement Architecture [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
IV.2 Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
IV.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
IV.4 Client Side Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
IV.5 External APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
IV.6 Admin: Template list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
IV.7 Admin: Add New template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
IV.8 Admin: Add New Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
IV.9 Admin: Add New Layout Element . . . . . . . . . . . . . . . . . . . . . . . . . . 65
IV.10Admin: Edit Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
IV.11Admin: Manage Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
IV.12Client: Choose Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
IV.13Client: Fill Page Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
IV.14Client: Landing Page Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
IV.15Client: Mailing List Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
IV.16Client: Classic Picture Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
IV.17Client: Mobile View on the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 72
IV.18Adding Web Semantics interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
IV.19Client: Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
IV.20Client: Managing Pages interface . . . . . . . . . . . . . . . . . . . . . . . . . . 73
IV.21Client: Page Analytics Interface - Daily Views and Interactions . . . . . . . . . 74
IV.22Client: Analytics: Daily Conversion Rate - Total Conversion Rate . . . . . . . . 74
v

List of Tables
I.1 Available solutions strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.2 Available solutions weakness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
II.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
III.1 MVP Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
vi

Abstract
The landing page builder provides intuitive and simple interface to start-ups and individual
to create and customize their product or service landing page. The client is oﬀered a set
of templates to customize as well as a group of competitive features as ergonomic editor,
monitoring page analytics and search engine optimization.
vii

General Introduction
The world wide web has evolved through the last decades enormously, it was built initially
around a pyramid shape. Webmasters prepare and send information to users but they can’t
actually respond to it, except in the forums or by mail. In Web 1.0, the Internet is passive.
Producing and hosting content are primarily by companies. The pages are static, sometimes
without updating the information provided. In the Web 2.0, users are more active: as when
they are browsing, users add content through links and other tags, annotations or comments.
The content is generated by users thanks to the emergence of blogs, wikis, citizens newspapers
and all new media are real discussions spaces of expression, exchange and debate. The user then
becomes a source of information and designs, the concept of emerging collective intelligence.
Now, the software is being released from personal computers. Many applications are now
directly accessible on-line. Beyond this aspect, our Internet environment is gradually trans-
formed into a true information ecosystem. In the future, we will be completely immersed in
the Internet. The presence on the Internet is not an option any longer and it’s met in the other
hand with the business requirements. New concepts emerges with the technology evolution and
we are talking now more and more about semantic web, connected objects, 3D web, cloud com-
puting...We are now trying to get more information about what a user do once he’s exploring
the web and to give more accurate results on search engine, for this, we don’t care anymore just
about the structure of a web page but also about what meanings and information it hides and
how those information and amount of data can be processed by machines and search engines.
With this immense evolution of the web comes an expansion of requirements and web page
development process. A web page today has to be accessible on various mediums and screens,
ranked on search engines, secured from web attacks as well as presenting it’s content in the
right way to attract users and leave the intended impression.
In the other hands, with business emerging more towards entrepreneurship and start-ups,
we have less deﬁned and stable visions towards a start-up’s products and services with more
ﬂexibility and orientation for change and experimenting products. A start-up is now faced not
only with time and money resources constraints but also with the web requirements .
1

Chapter I
Environment Analysis and Preliminary Study
Outline
1 Overview of the hosting company . . . . . . . . . . . . . . . . . . . . 2
2 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 The Software Development Methodology . . . . . . . . . . . . . . . 3
4 State of Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Overview of existing solutions . . . . . . . . . . . . . . . . . . . . . . . 4
5 Project Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 Web 3.0 and Semantic Web . . . . . . . . . . . . . . . . . . . . . . . 7
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Overview of the hosting company
iLathys PTE LTD is a web and corporate video production start-up based in Singapore. Co-
founded in 2011 by Jean-Christophe Bouglé and Sophie Normand. iLathys is composed mainly
of a marketing and web development teams. The marketing one focuses on corporate video
production and commercializing web solutions built by the web development team in which my
graduation project had place.It is composed by around 10 web developers and software engineers
between Singapore and Philippines and they are working on diﬀerent projects maintained and
promoted by the company or its partners.
Figure I.1 – Company Logo
2

I.2 Problematic
2 Problematic
On one hand he increasing necessity of presence on the web was met with the evolution of the
different technologies and with that we have more and more requirements for our presence on
the web. Today a web page must not just present your company or your product but must
be also available on different mobile and high resolutions devices, providing more interactivity
with the user, a maximum visibility on the web and search engines, a modern UI and design
and all that with the least page loading time. With all those requirement, the web accessibility
has enhanced increasingly but with that did also the web pages development, publishing and
management times. On a business level, a company nowadays meet with those requirements
of presence on the web with it business requirements and respecting it delays. The process of
creating a single web page for promoting a product or a campaign requires more and more time
and human resources.
On the other hand, the tools simplifying the web pages creation did not evolve enough to
meet the new web criteria. For one part, many of those tools are too complicated and requires
a minimum development knowledge from their users. Second, those tools are either providing
too much flexibility and don’t provides much rules or criteria for web page creation that prevent
the user from ending with an unbalanced UI, code or features... or they don’t provide enough
options and features for page customization and managements.
3 The Software Development Methodology
For managing our project, we followed an Incremental process of development based on agility.
Agile methodology is an iterative and incremental approach, which is conducted in a collabora-
tive spirit with just enough formality. It generates a high quality product while taking account
of changing of our needs.
Agility is primarily a state of mind that is based on the incremental development. This last
takes into account the fact that software can be built step by step. It consists of successively
carrying usable function elements, rather than technical components. The software is designed
and specified as a whole. The realization is done in increments features. Each increment is inte-
grated to all preceding and each step the product is tested operated and maintained as a whole.
The cycle followed throughout the project is incremental development. In fact, it’s about
studying the subject globally and this through requirements analysis followed by the functional
3

I.4 State of Art
specification and overall design.
4 State of Art
4.1 Introduction
We compare in this section the existent technological solutions and we link up with our pro-
posed solution to the presented problematic. We finish by explaining some of our proposed
solution technical notions.
Usually companies and start-ups are faced with an obligation to promote a product or a
service on the web through it’s own web page and assure his presence on the web. In such cases
the company is also faced with environmental and financial requirements as budget, investment
and delay. Those keys requirements are more critical for start-ups as they are in a continuous
development and change with no much capacity of handling long term investments. We present
above the different solutions available for creating a web page and specifically a sale page with
their limits.
4.2 Overview of existing solutions
4.2.1 WYSIWYG Rich HTML Editors
WYSIWYG stands for "What You See Is What You Get". In WYSIWYG HTML editors, you
create your web page without the need of web development knowledge. You are provided an
interface with components you will most likely add to your web page, you only place those
components on the right place of the page and then the editor take it from there and generate
the corresponding source code to your actions. Those component correspond basically to the
HTML tags: Link, Headline, paragraph, picture. . . As examples of those editors we mention
Adobe Dreamweaver, Microsoft Front Page (not supported anymore).
Although those editors don’t require a technical knowledge from the user, the web page
design and structure are handled to the user and they are mostly criticized for the boiled code
they produce and strange behaviours on mobile devices.
4.2.2 Web Content Management Systems
"A WCM is a Web Content Management system. These systems are designed to provide your
organization with a means of putting your business on-line with relative ease. A WCM, on
4

I.4 State of Art
a basic level, will offer such features as: easy content editing, versioning (revisions of your
content), media management, work-flow management for content approvals and publishing,
template modification and an easy to use dashboard of sorts to provide you with an overview of
your site(s)." [2]
Web content management systems facilitate the web pages development process and the
web page design with features such templates integration. However they require a minimum
technical knowledge and they are more designed to develop and administrate web blogs and
pages based on content sharing more then sale pages. As example of web content management
systems we mention Wordpress and Drupal.
4.2.3 Web Page Development from Scratch
One of the options for creating a web page is to develop his sale page from scratch and to
go through all the process and the different parts: page design, client and server side web
development, mailing systems integration, mobile support. . . Although this option would give
it the most flexibility and approximately a total control of the results, it will be also the most
expensive in terms of price and time.
4.2.4 Comparison
Tableau I.1 – Available solutions strengths
Strengths
WYSIWYG Rich HTML Editors
- Flexibility.
- Non-technical knowledge required.
- WYSIWYG Interface
Web Content Management Systems
- Flexibility
- Web pages administration.
Web Page Development from Scratch - Control over results and work on details.
5

I.5 Project Presentation
Tableau I.2 – Available solutions weakness
Weakness
WYSIWYG Rich HTML Editors
- Complexity: Design, Mobile Support and Page Structure
are all handled to the user.
- Unstructured Source Code and hard to maintain.
- Price: The inexpensive editors are limited in
functionalities and produce worse results.
Web Content Management Systems
- Minimum technical knowledge
- Designed for content sharing pages and not salespages
Web Page Development from Scratch
- Requires Technical knowledge and specialized
developers and designers.
- Price: Developers and Designers salaries,
deployment... or web agency service price..
- Time: The development and test process time grows
exponentially.
5 Project Presentation
To solve the problems cited in the problematics and to overtake the limits of the existing so-
lutions, iLathys choose to develop a solution specific for sales page and start-ups requirement
which is the Landing Page Builder.
"A landing page, sometimes called a destination page, is the web page that visitors arrive
at after they click the link on a search engine results page. This page generally displays logical
information, usually something that pertains directly to the keywords searched, or has the key-
words directly on the page. This can be a transactional or a reference page as well. In pay per
click and other paid inclusion campaigns the landing page is considered the place where “the
deal is closed” which basically means that visitors decide on the landing page whether they are
going to use the service of the web page or not." [3]
A landing page is a single web page site that present or promote a product or a service
having as main goal making a user a potential new client. The proposed landing page builder
is a web application that offers a WYSIWYG interface to build a web page from a template.
This choice explore the advantages of the HTML editors with its WYSIWYG interface without
incurring boiled code or in-congruent web pages as the landing page builder functionalities are
limited and based on the ones needed for the sales pages. From the other hand, the landing
page builder explores the advantage of web content management systems by offering a template
based web page builder which assure page consistency as well facilitating the web page design-
6

I.6 Web 3.0 and Semantic Web
ing. The landing page builder offers a big set of templates to choose from with an appropriate
customization flexibility. As the landing pages are designed essentially as sale pages, the landing
page builder provide mailing systems and analytics tools integration which facilitates adding
“subscribe to newsletter” sections on landing pages and monitoring page views and conversion
rates.
Those feature facilitates web page monitoring and administration without the necessity of
coding or additional components integration which provides to the client the necessary func-
tionalities to promote his product as well as observing the page’s analytics.
The landing page are by definition a destination page or page reached through search en-
gines. To optimize search engine rank and page visibility we decided to get use of web semantics
markups by providing an interface to add meaning and semantics markups to the landing page
content so it becomes more comprehensible by search engines and helps the right target and
conversions.
The Landing page builder project will be integrated as a feature in a web platform, developed
by iLathys and promoted by their marketing partner, called Fireup offering various features to
entrepreneurs and start-ups.
6 Web 3.0 and Semantic Web
The term Web 3.0 is used in the short term futurology to designate the Web that follows Web
2.0 as the next step in the development of the World Wide Web. The actual content is not de-
fined by consensus,the term is used to describe the vision of the future Internet. The semantic
Web is referred sometimes as web 3.0 but clearly it’s only a part of web 3.0. Its main goal is
to guide the evolution of Web in a way that allows users to find, share, combine information
without any intermediate interventions. Semantic web is a vision for the information to be read
by machines as well as humans. Giving machines the ability to understand not only words and
structure but also their meaning is what the semantic web is all about.
It is certainly not as simple as it sounds and giving the immense content of the web makes
transforming it to a semantic web a tedious task but many solutions are starting to take place
such as languages specifically designed for data like Ressource Description Framework (RDF),
MicroData and MicroFormat.
Semantic web is a newborn concept and still in its early days but as the technologies are
7

I.7 Conclusion
getting combined and invented, we will certainly see a breakthrough and significant change in
the web in the next years. Google, bing and yahoo already started a project to add meaning
to HTML pages content using RDF and other formats through a standardization of set of
attributes defined and described on schema.org.
7 Conclusion
This chapter detailed the technological solutions that exist and it treated the possibility of
reuse or inspiration from those. We also presented the proposed solution to our problematic as
well as defined and explained some notions.
In the next chapter we start detailing our functional and non-functional requirements
8

Chapter II
Requirements Analysis and System Speciﬁcation
Outline
1 Template Layout Description . . . . . . . . . . . . . . . . . . . . . . 10
1.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Layout elements structure . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Actors Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 The Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 The Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 15
5 Use Case and Functional Requirements Modeling . . . . . . . . . . 16
5.1 General Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Use Case: Create Landing Page . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Use Case:"Manage Landing Pages" . . . . . . . . . . . . . . . . . . . . 21
5.4 Use Case:"Create Template" . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5 Use Case:"Manage Templates" . . . . . . . . . . . . . . . . . . . . . . 25
5.6 Use Case:"Manage Client Pages" . . . . . . . . . . . . . . . . . . . . . 25
5.7 Use Case:"Visualize Landing Page" . . . . . . . . . . . . . . . . . . . . 25
5.8 Use Case:"Subscribe to NewsLetter" . . . . . . . . . . . . . . . . . . . 26
Introduction
The requirements speciﬁcation is one of the most important steps and the most decisive in
the realization of a project. It’s used to identify the key actors and the various features of
the application to be developed. In this chapter, we clearly show our application requirements
that must be taking into account in the solution to be developed. We expose the functional
9

II.1 Template Layout Description
and operational needs via the description of the main actors involved and their functionalities
through the use case diagrams and activity diagrams. We present also a description of the
chosen templates structure.
1 Template Layout Description
1.1 General Structure
Before detailing our application different use cases, we start by explaining the landing page
builder templates layout to facilitate the understanding of the application and the different use
cases. The creation of landing pages is based on templates defined and added to the system by
the application admin. Those templates contain the main structure and design of the landing
pages with placeholders to the elements that should be added later by the client on page cre-
ation.
Figure II.1 – Template structure
10

Figure II.2 – Template layout
11

1.2 Layout elements structure
A template is composed of a number of sections.That give us flexibility to distribute a section
on more than one template and to give the client the flexibility to customize the sections of
a template on page creation. For example this facilitates giving the client the hand to add of
some sections from a template B to a template A that don’t contains the required section or
to add premium sections on page creation. A section could be of three types: Header, Body or
Footer. A template is composed of a one header, one footer and a multiple body sections.
The sections are composed of layout elements which are the placeholders that will be filled with
the appropriate values on page generation. The layout elements could be of various types and
could be complex or simple.
Layout Elements types
1. Simple Elements:
• Text Element: Placeholder for a text content. It could be for example, a headline
or a description.
• Picture Element: Placeholder for a picture. It receives a picture’s path. This
element could hold for example a company’s logo or a background picture.
• Video Element: Placeholder for a video. It receives a youtube or vimeo valide
video link. It serves to embed a company’s video presentation or an event’s teaser
for example.
2. Complex Elements: The complex elements are on their part also composed of layout
elements and encapsulate different properties. Those element could be:
• Button Element: It’s composed of a link and a text element, the first holds the
button onaction link and the other the button value or title. It may be used on
page generation by the client to redirect his page users to an external content for
example.
• Mailing Element: The mailing element facilitate the integration of “subscribe
sections” in a landing page. It encapsulates the client’s mail provider configuration
and access tokens. The mailing element contains also a text element that holds the
subscription button’s text.
Each layout element also encapsulate a set of rules to assure the quality of inserted data on
page creation and to help insuring a minimum quality of generated pages from a given template.
12

II.2 Actors Description
Some of those rules are general and not specific to a given template, which mean the rule is
applied to all layout elements of a certain type. Other rules are specific to a template and are
specified by the admin on template creation. The table II.1 iterate those rules.
Tableau II.1 – Rules
Layout Element Type General Rules Specific Rules
Text Element Type String
-Maximum character number
-Minimum character number
-Required / Not required
Image Element Image File (.jpg, .png)
-Picture minimum width
-Picture minimum height
Video Element
-Valid Vimeo or Youtube
-LinkExisting
-Video
Required / Not required
Button Element
-Title: Type
-StringLink: Valid Link
-By inheritance the button’s title has
the same specific rules as the text element
Mailing Element
-Valid Credentials
-Submit Button Title: Type String
-By inheritance the submit button’s title
has the same specific rules as the text element.
In addition to the rules, a layout element specification describe also the default value or
content the element receive on page generation in case it’s not a required element. This default
value is also used to generate the template preview.
2 Actors Description
Our application is offered for 3 parts:
1. Administrator: It’s a special user that is responsible of adding and maintaining tem-
plates. He has access also to client pages with the same privileges as the client for support
purposes.
2. Client: He’s the application main user. He creates and maintains his own landing pages
from a template. The client has also access to his page analytics and stats. He also has
the choice of downloading his generated pages’ source code to deploy them on his own
server.
13

II.3 Functional Requirements
3. User: He the final user of the generated pages by our application. He only accesses the
pages and interact with the mailing system through our web service.
3 Functional Requirements
3.1 The Client
Generating Landing Pages: The client has the possibility to create and generate his own
pages from a template. The landing page creation involve those different steps:
• Choosing a template from the collection of templates the application provide.
• Customizing the template and filling it with his details and resources. Those resources
could be of different types: Textual, Images and Videos. The template customization
should be limited by a number of rules settled by the admin side on template creation. The
client should be also able to configure a mailing box with his mailing system credentials.
This mailing box is provided in all the templates to give the final page user the possibility
to subscribe to the page associated newsletter. In addition to that, the client should be
able to save his changes without publishing and to undo his previous changes.
• After customizing his page, the client is offered a preview showing how the page will look
on generation.
• The page creation end by the publishing of the final page and providing its public link.
Maintaining Landing Pages: After page generation, the client is offered the possibility to
edit his page or an older version of the page. He’s offered also the possibility to unpublish a
page or to save an edited one as a draft.
Monitoring Page Analytics: The client is offered also the possibility to monitor his page
daily analytics and other specific rates as conversion and sales rates instantly. The client should
also be able to connect his page to his own tracking system in addition to our system.
Export Landing Page HTML: It’s the possibility to download the source code of the gen-
erated landing page to deploy it later on their own server.
Enhance Page SEO with Web Semantics Markups: The application give the possibility
to add search engine recognized data to help improving page ranking and visibility on the web.
14

II.4 Non Functional Requirements
3.2 The Admin
Adding Templates and Sections: The admin is given the possibility to add new templates
and sections with the required rules and default content. A template is composed of sections
that are composed on their part of layout elements. More than one template can be composed
of the same section.
Managing Templates and Sections: The admin can edit and delete templates after creation.
Managing Landing Pages and Support: The admin can access and edit the client pages
to be able to fix issues or clear them up to the client in cases of support contact.
4 Non Functional Requirements
Ergonomie: In computer science, ergonomie is the capacity of a software or a web application
to be easily used by customers in order to realize the task it was designed to accomplish.
Ergonomic is a key part of our application as the main purpose of our application is to facilitate
web page creation through an easy to understand WYSIWYG interface. The application should
also be accessible on mobile device and with a responsive design.
Evolutivity and Maintainability: The application should be designed in a way to be
evaluative. This may be characterized essentially in two levels. First, the application should
provide an interface to add new templates to be used to create pages. On the other hand, the
application should be developed modularly and with the consideration of adding new features
and options in the future.
Rapidity and performance: With web advancement and especially with the increase of web
content accessed through mobile mediums, rapidity and performance become keen elements of
the web. In our case, the challenge is not only ensuring the rapidity and performance of our web
application but also of the generated pages. In addition to that, our application’s WYSIWYG
interface should provide instant previews of the user’s page while he’s customizing it.
Generated Pages Independence of our system: The generated pages should be indepen-
dent of our web application and system. For this reason the calls to mailing systems should
be realized through web service without necessity of interaction with our application’s stored
data. The mailing system access tokens should be saved in a secure way with the page to avoid
connecting to our database on each call to retrieve the mailing system credentials of a page.
Security: Attribute different access rights for different part of the application and securing
different data interchange.
15

II.5 Use Case and Functional Requirements Modeling
5 Use Case and Functional Requirements Modeling
Requirements modelisation is illustrated by different diagrams: use case, sequence and activity.
The modelisation is realized with the modelisation software: Visual Entreprise Architect for
UML as it provide an easy to use interface and a suffisant enough diagrams for our requirements.
5.1 General Use Case Diagram
The general use case diagram allows us to segment the main functionalities provided by our
application among different actors as much as distinguishing the different interactions between
the actors and the system.
The main required functionalities from our application are modelized by the Figure II.4that
represents the general use case.
16

Figure II.3 – General Use Case
We will detail in the next sections each of the general use cases illustrated in Figure II.4.
17

5.2 Use Case: Create Landing Page
The figure below details the functional requirements of creating a landing page:
Figure II.4 – Use Case:Create Landing Page
"create landing page" use case regroup those three use cases:
• List Template: Display the different available templates with the ability to filter tem-
plates by tags.
• Fill Template: It represents the main functionality of our application. It provide an
interface to the client to customize a template. It also extends a set of functionalities.
18

• Download Landing Page: After creating his landing page, a client has the option to
download his page’ source code to deploy it on his own server our make further edits on
it.
Figure II.5 – activity diagram : create landing page
For a better explanation of our application functionalities and the ﬂow of the diﬀerent steps,
we present a textual explication of the use case "Create Landing Page" that covers the major
steps of creating a landing page:
19

Description of use case "Create Landing Page":
• Actor: Client
• Trigger Event: Click on the button “Create Page”
• Goal and interest: The client wants to create a new landing page.
• Precondition: Authentication
• Postcondition: Generated Page or A Page Draf.
• Detailed Scenario: To create a Landing Page, the client starts by exploring the available
templates. He can choose a template or filter first the template list by choosing a tag .
Once a template is chosen, He enter his page details which are basically the page title,
description, favicon. . . Once he submit the page details, a new page is created containing
the provided informations. After that the client is redirected to fill his page content
and fill the template he choose with his content. He can add web semantics markups
to improve his page visibility on search engines and he can also preview his page before
saving. Once he finish filling his page, he can save or publish his page. The two actions
will take place only after validating the inserted page content and checking that it mates
the template rules and requirements. If it’s not the case, the client is returned to the fill
content page with error messages so he can recheck his entry. Once he passes the rules
validation, the page is saved or published according to his request. After publishing his
page, the client can download it. In case the client save the page and doesn’t publish it,
the page is saved as a draft so he can continue working on later and starts from where he
stopped.
20

5.3 Use Case:"Manage Landing Pages"
Figure II.6 – Use Case:Manage Landing Pages
The "Manage Landing Page" use case regroup the following functionalities:
• Display Landing Pages: The Client can list the landing pages he created with history
of different published versions and landing page drafts.
• Delete Landing Page: The Client can delete a landing page or a specific version of it
• Edit Landing Page: The "Edit Landing Page" use case extend the same functionalities
as the use case: "Create Landing Page".
• Display Analytics: Show the stats of a specific landing page.
• Edit Landing Page State: Unpublish or publish a landing page.
21

5.4 Use Case:"Create Template"
Figure II.7 – use case : create template
The use case "Create Template" regroup this set of functionalities:
To create a template, an admin create a number of sections that compose this template. Those
sections could have one of those three types: Header, Body or Footer. After that, the admin
select the speciﬁc sections that compose his template. A template should be composed of one
header and one footer and at least one body.
When creating a section, the admin creates the layout elements that contain this section and
specify the rules that are applicable for this element.
22

Figure II.8 – activity diagram : create template
23

For a better explanation of the use case "Create Template" that covers the major steps of
creating a template, we provide this textual explication. As the template creation process is
composed of the use cases "Create Section" and “Add Template” we describe each.
Description of use case "Create Section"
• Actor: Admin
• Trigger Event: Click on the button “Create Section”
• Goal and interest: The admin wants to create a new section.
• Precondition: Authentication
• PostCondition: Section created with it’s elements.
• Detailed Scenario: To create a section, the admin starts by filling the section details
(name, type, source code file...). Once done, a new section is created and he got to choose
whether or not he want to add elements to the section. If it’s the case, he fill the element
specification (name, type, specific rules, default content...) then he save the element and
choose whether to add another element or finish.
24

5.5 Use Case:"Manage Templates"
Figure II.9 – use case : manage template
The "Manage Templates" use case is composed of these set of functionalities:
• The Edit Template: is similar to the "Create Template" use case detailed in section
II.7 except that instead of adding sections to a template you get to change your previous
selections.
• Delete Template
• Preview Template
5.6 Use Case:"Manage Client Pages"
To facilitate customer support and to manage landing pages, the admin can list and access the
diﬀerent pages created by the clients with the edit rights.
5.7 Use Case:"Visualize Landing Page"
The landing page visualization can take place on our platform or on our client’s personal
server. In both cases, even if the passage through our platform is transparent to the landing
25

page user, the visualization of the landing page still a part of our system functionalities. On
page visualization, severt calls to our RESTful webservice take place transparently to track
views counts and other interactions on the page.
5.8 Use Case:"Subscribe to NewsLetter"
On our different templates we provide the client side of a subscribing to mailing list system.
After the subscribing system is configured by the client and the page is generated, the final
user of the page got the opportunity to subscribe to the newsletter of our client. To do so, a
RESTful call is send to our web service where we could handle the request and subscribe the
user to the right mailing system. As the “Visualize Landing Page” use case, the “Subscribe to
NewsLetter” use case pass through our system in a transparent way of the final user.
Conclusion
In this chapter, we have summarized our project specification in the form of functional and
non-functional requirements. In the next chapter, we will put the flat Detailed design of these
needs as well as the architecture of the solution adopted
26

Chapter III
System Design and Architecture
Outline
1 Operational Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 Applicative Architecture : . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Page Generation Mechanism . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Solutions Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Template Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Generated Page Structure . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 General Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 WYSIWYG Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Introduction
1 Operational Architecture
The landing page builder follows the three-tier architecture pattern where our application is
composed of those tiers:
• Client side: web browser based that enables the diﬀerent actors to access the application.
Our client is basically a thin client as for most of the parts of our application it is only
responsible of rendering the returned HTML from the server and sending HTTP requests
to the server to handle. However for the WYSIWYG editor, where the client get to ﬁll
his page content and live preview the changes, the client side is responsible for rendering
the template as the client makes his changes without directly interfering with the server
until the client choose to save his work or publish the page. We will get more deeply on
the WYSIWYG editor applicative architecture on the next sections.
27

III.1 Operational Architecture
• Middle tier: it’s the web server that deploys the different layers of the application as
the views and business logic.
• Data tier: composed of the database server and files storage server.
Figure III.1 – Operational Architecture
The generated landing pages are saved on the file storage server. They can be accessed
through our application or through the client’s own server. Most of the landing page content
is static, although, the page makes transparent RESTful calls to our web services for analytics
and mailing system purposes.
Figure III.2 – Landing Page Architecture
28

III.2 Applicative Architecture :
2 Applicative Architecture :
In opposition to the operational architecture where it’s about distinguishing the diﬀerent phys-
ical layers, the applicative architecture interest in logical decoupling of the application and to
the way we regroup the diﬀerent components switch their type and the tasks they accomplish.
Our application server side code follows the Models-View-Controller design pattern:
• View: This layer contains the web application pages
• Controller: It is responsible for the two way binding between the models and views. It
receives the request and make the appropriate treatment. A request object is injected to
the controller that is responsible of validating the HTTP request data before passing it
to the controller.
• Models: This layer is responsible of data manipulation. It contains the entire entities
of our solution and they are mapped into persisted objects of our database tables using
object-relational mapping.
Figure III.3 – MVC Decoupling
29

III.3 Page Generation Mechanism
3 Page Generation Mechanism
3.1 Solutions Comparison
The main functionality and purpose of our platform is the final page generation, for this reason
we describe in this section further the steps of page generation with the different technical
choices. We start by describing the different parts involved in the page generation:
• Template: The template is a standardized non-executable file that holds a landing page
structure and initial content with placeholders for additional content. The admin describe
a given template file structure and the elements that it receives in a template object that is
persisted in the database with the template file path. Mapping the template file structure
into relational objects reduce the necessity of accessing and parsing the template file to
retrieve the template elements.
• Page Object: A page object is filled by the client with the content he associates to
each placeholder in the template. A page object is persisted in the database.
The template elements or placeholders are entitled “layout elements” and their correspond-
ing content objects filled by the client are called “landing page elements”. A landing page is
generated by filling a template’s layout elements with a page object’s landing page elements.
30

Figure III.4 – Page Generation Mechanism
So after our client finish filling his page content and the content is saved in a page object.
On publishing we retrieve the page object and the template file to generate the landing page.
As the template is composed of sections we need before to merge the sections files into one
file. The landing page generation depends of the templates format (or precisely the sections
format).Having that in mind, we tried to compare the different solutions we could put in place.
We end up with three main solutions:
• The first one consist of coding the templates as server sides view and render them with
the page object directly using the server side rendering engine. This consist of passing
the template file and page object to the server side view rendering engine and he’ll take
it from there with no need for us to parse the templates.
• The second solution consist of coding the templates in pure HTML and injecting to it
the page object as JSON. On request the HTML file will be returned without necessity
of server side view rendering but the landing page elements, injected as JSON, will be
injected on the appropriate fields on the client side.
• The third option is a combination of the two previous options. The templates are coded as
server side views and rendered using the server side views rendering engine and persisted
31

as HTML. On request we return directly the final HTML file without re-rendering and
accessing the database each time a landing page is consulted.
We compare the different options in the table below:
32

Figure III.5 – Comparative table
As our main concern is to build better landing pages with better personalization as much
33

as better accessibility, also that landing page consulting requests will naturally be much higher
and more frequent than the landing page generation, we opted for the hybrid solutions. The
hybrid solution focalize on optimizing the landing page access time more than the generation
time or the complexity of the solution implementation
You will find below a graph representing the difference in request time between returning
static HTML and dynamic pages [4]:
Figure III.6 – static vs dynamic html time
1000 requests were made with two pages one a PHP page with 2 database queries and
another PHP cached as a static HTML, the Mean time for static HTML pages is only 0.515
ms and 102 ms for dynamic PHP. Although the experiment depends the environment it was
run on and it can’t be taken.
3.2 Template Layout
As the templates are coded using server side view, the template layout elements was encountered
in an expression and they make call a unified method to retrieve the right content from a page
object on page rendering. The use of a unified interface to access the landing page elements
facilitates the template writing as the admin is do not have to know our system or elements
architecture to create new templates. He only access the content using the section name, layout
element label and layout element property for composed elements.
34

Figure III.7 – Template Layout and Expressions
A template expression could be either content or expression or attribute expression:
• Content expression: is an expression inserted inside a HTML markup as a part of its
content.
• Attribute expression: is an expression as a part of an HTML markup attribute value.
3.3 Generated Page Structure
On the generated page, the expressions should be replaced with the entered content by the
client. In addition to that we inject additional attributes in the generated HTML The client
is oﬀered an interface to add semantic and meaning to the content he entered and an initial
category to the page that will be injected in the generated page header as an item property,
after that the entered content is injected using “property” attribute to the diﬀerent element
and conformal to schema.org structure.
Figure III.8 – semantic markups
35

III.4 Design
The generated page contains also tags to track page views and buttons clicks. As the seman-
tics markups, those markups are also injected on template rendering with elements content.
Figure III.9 – tracking tags
4 Design
4.1 General Design
4.1.1 Class Diagrams
The separation of the problem to subparts helps refining the technical specification. Thus,
adequate distribution of the load between the different layers helps better organizing treat-
ments and interactions between classes, which improves the quality and management of system
components. Our application is separated mainly into three layers which are: Model, View
and Controller. The models are the representation of our application’s data through object-
relational mapping (ORM). The model classes holds also the business logic and treatments that
can be executed on. The views holds our different application pages structure and information.
The controller plays the role of the glue between the different layers and redirect retrieved re-
quests to the right destination. Our application is composed also composed of requests classes
that may be counted as a part of the controller layer. The requests class validates the retrieve
HTTP requests with a set of defined rules.
We present with the following class diagram our application main controllers. The "Land-
ingPageBuilderController" retrieve and handles the requests made by the client while the "Ad-
ministrationController" take care of the admin requests and template administration part of
the application.
36

III.4 Design
Figure III.10 – class diagram : Controller
We present on the following class diagrams the diﬀerent request classes.
Figure III.11 – class diagram : Request
We present on the following class diagram our model classes. We can group them in three
categories. The main category represent the application main structure and the communication
between the diﬀerent data models. The other two holds the information related to the statistics
and web semantics markups.
37

III.4 Design
The landing and layout elements could be of diﬀerent types (Text,Picture,Video,Button,MailingList)
and each of those has its own properties and rules. As relational databases don’t support in-
heritance we implement Martin Flower single table inheritance approach. [5]
Figure III.12 – class diagram : Model
38

III.4 Design
4.1.2 Sequence Diagrams
4.1.2.1 Saving and Generating Behaviours
In what follows, we present some sequence diagrams with a behavioral view of the system, more
specifically, the communication between the layers.
We start by the sequence diagram of Figure III.13. The diagram shows the different steps
for saving the landing page content. To do so we run through the different template layout
elements and retrieve the corresponding element on the client request. If the user didn’t give a
value to this element yet, it receives the default value set by the admin on template creation.
In the other case, the entered value is validated with the corresponding layout element rules
and persisted if it passes the validation.
39

III.4 Design
Figure III.13 – Sequence diagram : Landing Page Saving on server side
40

III.4 Design
On page generation, we start by merging the template file composed of the different sections
files. Once done, we pass the file as view to our view rendering engine with the landing page
object. We provide a unique facade to access the different landing page elements. On page
rendering, the views rendering engine makes several calls to the landing page object getContent
with the element section and label properties. The landing page retrieve the requested element
and return its content with additional tags depending on its type. For the text, picture and
video elements, we add the web semantics data in case we have any and for the buttons we
add a tracking code to track clicks. For the mailing list, we encrypt and inject the mailing list
credentials in the subscribe link so we don’t have to retrieve them from the database on each
subscribe request to a mailing list, we also add a tracking code to track conversions. For the
mailing list and button childs, they are handled with their type not their parent type.
Once the views rendering engine terminates the template rendering we persist the rendered
HTML to be returned on landing page consulting requests. We present on the following diagram
the page generation use case.
41

III.4 Design
Figure III.14 – Sequence diagram : Landing Page generating on server side
4.1.2.2 Landing Page Behaviours
Although the landing page can be deployed on the client’s server it still connects to our
42

III.4 Design
systems through RESTful calls. Even if the landing page is deployed on the client’s server, it
still sends views and clicks data to our server and the client can monitor his page activities and
analytics through the dashboard we provide. We present on the following section the diﬀerent
scenarios and use cases where the landing page makes remote calls to our web server. The
following sequence diagram represent the subscribe call that takes place when a user subscribe
to a client’s mailing list.
We retrieve the mailing credentials from the encrypted link [6] and we connect to the mail
provider through their APIs to subscribe the user. This module is loosely coupled to our system
as it doesn’t require retrieving the credentials or other persisted data from our system or relay
to other of our system modules.
Figure III.15 – Sequence diagram : Landing Page Mailing List Subscription
43

III.4 Design
On page generation we add tags and scripts to the page so we can track user interactions
and provide the client a dashboard with his page analytics. We present on the next diagram
this behaviour.
Figure III.16 – Sequence diagram : Landing Page Clicks and Views Tracking
4.2 WYSIWYG Editor
4.2.1 Architecture
The landing page editor facilitates landing page creation by offering a convenient interface to
customize and fill a template with the appropriate content. It offers to the client a form to
enter his page content and affect the appropriate value to each layout element. The client can
see a preview of the resulting landing page on the editor as he changes the layout elements
values.
44

III.4 Design
Figure III.17 – WYSWYG
As the main use cases of our application for the client is the creation and edit of the land-
ing pages, we evaluate an importance of optimizing the user experience on page creation and
minimizing the delay for returning a page preview. We have two main options for the landing
page preview on the editor:
• Making remote calls to the server on preview request, generating a preview from the filled
data, returning the preview html and displaying it on the editor.
• Parsing the template file on the client side and render it with the filled data to HTML
and bind the client’s inputs with the template placeholders.
Although the first option render the page preview directly using the chosen template ren-
dering engine, it causes more latency as each preview request requires fetching and retrieving
data from the server. With the second option we are able to provide instant previews on client
entries change. However this choice requires us to develop a client side rendering engine that
is able to read and fill our templates. Having that in mind.
45

III.4 Design
The editor offers various fundamental functionalities and our platform is centered upon
which mean that it will be affected by most changes and optimization we decide to make in
the future which increase the complexity of the client side code. Those reasons we decided to
decouple the editor client side code using an MV* pattern. The decoupling of the editor into
MV* application don’t only helps separating responsibilities but also binding the client inputs
to the landing page or preview elements.
After comparison of different MV* patterns [7] we chosen to implement the MVP design
pattern. We explain in the table below each layer’s responsibilities:
Tableau III.1 – MVP Layers
Model
The Model contains the landing page object and the landing page elements values.
It is pushed to the server to be saved once the client finish the page editing.
The Model uses the observer pattern to fire events each time changed.
View
We can split the views into two categories:
-The first contains the form and actions fields with which
the client interact with the editor and insert his page content
-The second contains the representation of the client entries
on the preview.In other words, it’s composed of the template layout elements rendered
with the client given page content.
We keep track of those views in the HTML so we can directly update them when
the client customize an element to avoid rendering the entire template file on each element change,
instead we only render the element’s corresponding view.
The view also handle directly the model change event.
Presenter
The presenter manage the communication between the views and the model.
It handles the view change events and pass the received data to the right model.
It access also the views in the cases that do not fall in the observer pattern.In addition to that,
the presenter take the role of initiating the editor and generating
the template’s HTML by parsing the template original file.
46

III.4 Design
Figure III.18 – MVP
4.2.2 Template Parsing and extracting layout elements
As templates are parsed on the editor to generate the views and the preview HTML, we define
a group of finite state machines that recognize our template’s different expressions. Once we
extract an expression from the template we extract the expression’s parameters and pass those
parameters to a new element view. Finally, we delete the expression from the template file and
add an attribute to the HTML tag containing the expression with the element view id.
We have two kind of expressions: attribute and content expressions. The first is inside a HTML
tag’s attribute and the other as a part of a HTML tag content. The "" and "" symbols are re-
placed respectively by the "{%”and”%} ” symbols on template retrieving from the server side
to prevent conflict with the server side view code.
Figure III.19 – Template Parsing code example 1
Figure III.20 – Template Parsing code example2
To explain our parsing algorithm and our process we devise the problem on subparts and
we explain each step with a state machine. We define first those two states machines that
47

III.4 Design
recognize each expression:
Content Expression:
Figure III.21 – Content Expression
Finite State Machine Description:
:{{%, %} , Character}
Q : {S0, S1, S2}
S : S0
F : S2
The Character symbol deﬁnes the diﬀerent HTML character except the {%and the%} sym-
bols.
48

III.4 Design
Attribute Expression:
Figure III.22 – Attribute Expression
:{{%, %} , <, >, Character}
Q : {S0, S1, S2, S3, S4}
S : S0
F : S4
The Character symbol deﬁnes the diﬀerent HTML character except those symbols: {%, %} , <
, >
Once we recognize an expression we extract the expression parameter to know it will hold
the content of which model element. The following state machine recognize the parameters of
an expression.
49

III.4 Design
Figure III.23 – Parameters recognition
:{(, ), ,, Character}
Q : {S0, S1, S2, S3, S4, S5, S6}
S : S0
F : S3, S5, S6
The Character symbol defines the different HTML character except those symbols: ( , ) , ,.
To modelize the entire template parsing and the rendering of the first empty preview we
use a finite state machine with output. That facilitates representing the expression delete on
rendering and the injection of the identifiers in the resulting HTML.
50

III.4 Design
Figure III.24 – Template Parsing
: {{%, %} , <, >, ”, Character}
Q : {S0, S1, S2, S3, S4, S5, S6}
π : {Character, <, >, ”, $}
S : S0
The Character symbol deﬁnes the diﬀerent HTML character except those symbols: {%, %} , <
, >
We output directly a composition of symbols to minimize the state machine diagram.
Result of rendering a content element:
Figure III.25 – Attribute element rendering
51

III.4 Design
Result of rendering an attribute element:
Figure III.26 – Content element rendering
4.2.3 Sequence Diagram
We present with the following sequence diagrams a representation of the communication flow
between the editor’s different layers.
On fill page opening, the presenter take care of initiating the editor and generating the different
model objects as well as the default page preview. To do so, the presenter starts by parsing
the template file that is injected as a string object. After that, the presents create the different
model objects composing the landing page with their default values.
On parsing, the presenter selects the different expressions and generate a view object for each
one of them with the appropriate properties. The view object holds his expression as well as
an unique identifier. Once a view is generated the presenter delete the expression from the
template and add an attribute to the HTML element containing the expression with the cre-
ated view object id. This way we can select directly the HTML DOM element that should
receives the rendered expression value on model change and avoiding parsing and rendering the
entire template on each change or preview request. Once the presenter finishes transforming
the template to HTML, it inject it inside the "fillContent" page’s HTML. When all initiation
terminates the presenter hides the loading screen.
We explain further the editor initiation with the following sequence diagram.
52

III.4 Design
Figure III.27 – Sequence diagram: Parsing
The sequence diagram of the Figure III.30 represents the filling of an input element by the
client and generating the preview of the filled element by the editor.
After the client fill an input element’s value (a headline, a logo or a background picture for
example), the presenter detects the input element value change, retrieve the input element label
and section identifiers and send the element’s new value to the corresponding model object.
The model object process the data and save it in the right format then fires a change model
event. The corresponding element view to the input changed field handles the model change
53

III.4 Design
event, render the new value and inject the new value into the preview HTML.
The binding of each layout element or element model object with a view reduce the ren-
dering time as we render only the changed element and inject the new value directly to the
pre-rendered HTML.
Figure III.28 – Sequence diagram: Input Filling
Once the client finishes editing his landing page or he reaches a respectable state he could
save the edited content. To do so, the presenter handles the clicks the save button and pass
it to the page object. The page object fills a FormObject with the different model elements
54

III.4 Design
content. The page then sends the FormObject to the server through a RESTful call. If the save
is successful, the page objects save the returned page id (in case of new landing page object
creation on the server side and not only the edit of an existing one). In case some elements
content were not validated, the presenter display them to the client so he can re-check. The
server side of page saving is described on section III.13. The following sequence diagram rep-
resents the save process on the client and editor side:
Figure III.29 – Sequence diagram: Client Side Save
55

III.4 Design
The next sequence diagram represents the page publishing use case on the editor side. To
publish a page, the client side page object calls it save method with a publish callback to exe-
cute if page saving succeed.
Figure III.30 – Sequence diagram: Page Publish
Conclusion
In this chapter, we describe the design of our solution in details. We have presented, at ﬁrst,
its general architecture that we have detailed thereafter through class diagrams and sequence
diagrams. We described as well our landing page and preview generation mechanisms. The
56

III.4 Design
tools used for the realization of our application will be described in the next chapter.
57

Chapter IV
Technological Tools and Implementation
Outline
1 Hardware and Software Work environments . . . . . . . . . . . . . 59
2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3 Human Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1 Admin Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2 Client Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Introduction
At this level, we detail the implementation phase of our application. We start by deﬁning the
hardware and software environment. Next, we explain our technology choices. We then present
screenshots of realized interfaces.
58

IV.1 Hardware and Software Work environments
1 Hardware and Software Work environments
Figure IV.1 – Deployement Architecture [1]
Our application is hosted on the cloud using amazon web services (aws). The web server is
over an apache php aws EC2 instance, the database over a mysql aws RDS instance and ﬁles
storage over aws S3.
59

IV.1 Hardware and Software Work environments
Figure IV.2 – Development Tools
To carry out our development phase, we have made use of the following softwares:
• PHP Storm: To develop our application in ergonomic conditions and institute an orga-
nization in the implementation we used the PHP Storm IDE.
• Sublime Text: To develop the client side and some parts of the application.
• Mysql WorkBench: To manage our database instance.
• Homestead: It’s a virtual machine instance with the conﬁguration of an apache web
server. It’s used to test and simulate the web server locally.
• Git: Is used as our version control system. We used Bitbucket as our web based code
hosting service for our git project.
• AWS command line: To deploy the changes made locally on our amazon web service
instance.
• Enterprise Architect and FSM Simulator:for the drawing of diagrams and ﬁnite
state machines.
60

IV.2 Technologies
2 Technologies
We present in this part of the various technologies used in the implementation of our solution.
Figure IV.3 – Technologies
Our application server side is implemented using the framework Laravel PHP, Laravel is
an MVC open source web framework that comes with diﬀerent features as packaging system,
dependency management with integrated ORM systems and a view and templating engine. We
use the 5.1 release of Laravel.
Laravel comes with a templating engine called Blade that is used as a scripting language to
implement the application views. We use the same templating engine to write our application’s
templates. The Blade templates expressions are hold between double curly braces "{{...}}"
which helps converting them to the right template format that we are parsing on the editor
"{%...%}" as well as being directly processed on the server side.
Additional to the templating engine, laravel also comes with an ORM called Eloquent that
abstracts the database access and provide a direct mapping between the database tables and
application’s models.
Figure IV.4 – Client Side Technologies
61

IV.3 Human Machine Interface
For the editor, developed on the client side, it’s implemented using the javascript object
oriented approach for the editor’s logic and base functionalities, HTML5 and CSS3 for the
UI structuring and styling. The implemented UI accept drag and drop actions provided with
HTML5 for a better user experience.
Client side plugins as jQuery and Bootstrap are used to implement the basic client side
functionalities on the different application’s pages as well assuring the application accessibility
on mobile devices. We also use FontAwesome for the different application icons.
We use a javascript plugin called Highcharts to draw the analytics charts on the client’s
dashboard.
Figure IV.5 – External APIs
To develop our application’s various functionalities we make use of different APIs. or user
subscribing to a client’s mailing list we connect to the Mailchimp, Aweber and InfusionSoft
APIs. We also make calls to amazon web services to store uploaded files on Amazon S3 bucket.
Although, we implement our own analytics system, we also interact with Google Analytics Api
to access stats that are not provided by our system.
3 Human Machine Interface
After presenting the development environment, we present in this section the different HMI
interfaces realized.
3.1 Admin Interfaces
We start by the admin interfaces for creating and managing templates and sections as well as
managing the client pages.
62

Figure IV.6 – Admin: Template list
The admin can explore the list of created templates, ﬁlter them by tags, preview, edit or
delete a template as well as adding a new one.
63

Figure IV.7 – Admin: Add New template
64

Figure IV.8 – Admin: Add New Section
Figure IV.9 – Admin: Add New Layout Element
The Figure IV.7, IV.8 and IV.9 present the interfaces for creating templates, sections and
65

elements. After inserting the template details and tags, the admin is redirected to another
interface to select the template header, bodies and footer.
Figure IV.10 – Admin: Edit Section
The Figure IV.10 presents the interface for editing a section or deleting elements composing
the sections. We provide other similar interface for editing templates.
66

Figure IV.11 – Admin: Manage Client
The Figure IV.11 presents the interface for managing the client pages. The admin extends
the client’s functionalities for client support reasons.
67

3.2 Client Interfaces
Figure IV.12 – Client: Choose Template
We present next the client interfaces. We start with the homepage in which we list the diﬀerent
templates to the client.
68

Figure IV.13 – Client: Fill Page Info
Once the client choose a template, he’s redirected to the interface shown in Figure IV.13 to
enter his page details.
69

Figure IV.14 – Client: Landing Page Editor
Once the client ﬁnishes entering his page information, he’s redirected to the landing page
editor. The editor provides an ergonomic interface with drag and drop functionalities as well
as live previewing his changes. The interface also shows hint messages with the layout element
rules on element change.
Figure IV.15 – Client: Mailing List Setup
70

Figure IV.16 – Client: Classic Picture Upload
Figure IV.15 presents the conﬁg pop-up box for the landing page mailing list. As shown
in Figure IV.16the client can also upload his images the old way if he’s not willing to use the
HTML5 drag and drop.
71

Figure IV.17 – Client: Mobile View on the Editor
As shown in Figure IV.17, the client can also toggle the mobile mode to see how his page
will look on mobile devices.
Figure IV.18 – Adding Web Semantics interface
Once the client ﬁnishes customizing his page, he can add meaning to the content he intered
using an ergonomic interface. He select an element or a part of a text element then he select
the adequate web semantics property from schema.org properties list.
72

Figure IV.19 – Client: Errors
The Figure IV.19 shows the error messages displayed on the editor after page saving.
Figure IV.20 – Client: Managing Pages interface
Finally, once the client save and publish his page, he can display the manage page and list
his diﬀerent pages. The client can also publish or unpublish a page and go through his page
old versions.
73

Figure IV.21 – Client: Page Analytics Interface - Daily Views and Interactions
Figure IV.22 – Client: Analytics: Daily Conversion Rate - Total Conversion Rate
As well as providing various customization options on the manage page, we also provide the
client with a dashboard to monitor his page’s daily views numbers, conversion rates and other
instant statistics.
74

IV.4 Tests
4 Tests
To test the user experience and eﬃcacy of web services exposed by the back-end of our system,
we used an extension of the browser Mozilla Firefox called HTTPRequester. It provides
an interface to enter a web address, select the type of request (ie PUT, GET, POST other)
and display the response.
To test the landing Page Editor and the other Javascript functionalities of our client side, we
used the debugging tools provided with web browsers. We tested the site in three of the most
popular browsers: Chrome, Mozilla Firefox and IE.
Conclusion
This chapter is devoted to describing the development phase of our project. We have initially
presented our material environment and used softwares then various realised interfaces.
75

Conclusion and perspectives
Throughout this report, we presented the research, analysis, design and development made to
implement the landing page builder. The implemented application satisfies the functional and
non-functional requirements.
To achieve this result, we first started with a study of the existing systems after which we
identified the product requirements. Then we designed and modeled the different modules to
make the final implementation of the solution. During these different parties, we encountered
difficulties we have overcome gradually. These difficulties are mainly related to optimizing the
loading time of the landing page and the client side editor. We’ve been able to discover the
necessary rigor to realize a quality product.
At this stage, the developed solution validates our initial objectives. Nevertheless, it can
give due to possible changes in enriching by new features such as:
• Enhancing template customization options on page creation.
• Implementing new metrics and statistics visualization on the analytics dashboard.
• Adding the possibility to integrate premium sections to a landing page on creation.
76

References
[1] Amazon web services document. https://aws.amazon.com/fr/documentation/.
[website]. v, 59
[2] Mike Johnston. Web content management. https://www.cmscritic.com/
cms-or-wcm-which-is-which/. [website]. 5
[3] Brick Marketing. What’s a landing page. http://www.brickmarketing.com/
define-landing-page.htm. [website]. 6
[4] Brick Marketing. Load time of static html and dynamic php pages. http://ahoj.
io/load-time-of-static-html-and-dynamic-php-pages. [website]. 34
[5] Martin Fowler. Single table inheritance. http://martinfowler.com/
eaaCatalog/singleTableInheritance.html, (2003). [website]. 38
[6] OWASP. How to protect sensitive data in url’s. https://www.owasp.org/index.
php/How_to_protect_sensitive_data_in_URL’s. [website]. 43
[7] Martin Fowler. Further Enterprise Application Architecture development. Département
Math-info (2006). 46
77

National Institute of Applied Science and Technology Graduation Project Design and Implementation of a Landing Page Builder

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to National Institute of Applied Science and Technology Graduation Project Design and Implementation of a Landing Page Builder

Similar to National Institute of Applied Science and Technology Graduation Project Design and Implementation of a Landing Page Builder (20)

National Institute of Applied Science and Technology Graduation Project Design and Implementation of a Landing Page Builder