Realizarea Unui Magazin Online
=== Realizarea unui magazin online ===
Contents
Contents
INTRODUCTION
Background
The motivation for creating a web application which would help high-school graduates apply for admission at Technical University of Cluj-Napoca was mainly based on the fact that, especially people around high-school graduation age are constantly connected to the Internet and use it frequently.
This paper tries to present the development of a university web site running on a continuous integrated system. Also, this paper will present an analysis of some of the most popular technologies used in web development.
Seeing that nowadays the smartphones, tablets, laptops and personal computers are widely used by most people every day, we thought about how the responsive design feature should be mandatory in our application. This would make the content of a website adapt based on the size of the device used. This would make a better user experience and also make the application more user-friendly. The main reason we chose to create an automation tool was to enable us to adapt the application on the fly (add different tests, implement new features etc) and also to automate several tasks to avoid unnecessary repetition and time consumption.
Project Objectives
The aim of this project was to create a modern, responsive single page web application running under a custom created continuous integrating development system. Taking into account that nowadays most people rely on mobile devices such as notebooks, tablets and smartphones daily, the conclusion of adopting a responsive design was the one to go with in order to obtain the assurance of delivering a smooth, natural and intuitive user experience on all of the screen sizes available for these devices.
Another contemporary problem is the lack of time and by considering that and the fact that the highest part of our targeted audience consists of high-school graduates, most of them having smart-phones we considered that by creating a website for the candidates recruitment center we could fix the problems of wasting time and resources for the users of the application which would be actual candidates. One more thing we wanted to do was to build our website under our own continuous development integration system. All modern day application building workflows benefit a lot from having such a tool available simply because of the reason that if the developers create it from scratch, they can make it fit exactly to their own needs and the project’s requirements which can offer great advantages in terms of consistency and efficient time management.
Besides the overall idea of building a website and it’s custom integration system, another key component for us was the actual visual design since, after doing some research, the conclusion was that what the user actually sees on the page strictly visually, without interpreting any kind of written information has a very big impact on the overall user experience and, most importantly, on satisfying the user’s needs and influencing his decision wether to use the application or not.
Approach
One of the key moments when starting up a web project is choosing the technologies to be used since this decision may drown the developers into a pile of redundant, hard to read and wrongly architectured code or, if a good decision is made it can be a real life saver. Judging by the specifications and thoughts we have taken into consideration and presented above about building this project, the targeted stack would be a persistently running server which would serve as the integrator, a visual CSS framework which allowed the creating of a responsive design consistently and with ease and, of course, the most important part, a javascript framework which allowed client-side rendering in order to create the website as a single page application.
The planning process was set to be built over wireframes of how the end product would look in order to provide a nice visual-based feedback from a client and help us set ourselves a better idea of how the final project should feel and look in terms of design and page arrangement.
Considering the fact that we were a team of two, it was mandatory for us to set up a common repository in order to allow pair programming and contributions to the project and allow us to do this regardless of the place or time it is done. Also, using a feature like this would help in keeping the code safe, well organised and have an editing history for easy restoration in case of an unwanted event which would lead to the project’s deterioration.
In order to better present how we our application would look at an architectural level, a diagram was created which states the combination of all the finally selected technologies as a whole system. Each technology which is in the scope of this paper will be presented individually and the other components are better explained in Raul Dolha’s contribution to the project [8] but for the scope of this introduction, a short overview of the system will be presented as an introduction for the following chapters.
In the middle, surrounded by the yellow square we practically have the whole continuous integration system running under GulpJS. The core component of the application is AngularJS which is the first stage our assets and external files such as libraries and plugins get drawn into to be further exploited. The only external custom service that Angular connects to is an API for CRUD operations which is produced by a PHP codebase and persisted into a MySQL database. Since the javascript framework will be taking care of rendering the views, the newly prepared views are piped through a CSS framework which in our case is Bootstrap 3. This component will be taking care of styling the generated pages and handling their behaviour on different screen sizes as well as other visual functionalities such as performing animations or providing graphical sets of tools. At this point we already have a browser-ready code but, as this end application is meant to be a public one, just handing over the whole source code on a public domain without it being linted, tested or secured would not be enough.
This takes us to the next step which is actually building our code for a release or for further development. First, the code is piped through a JS syntax highlighter called a „linter” which displays basic syntax errors in a terminal window for easy and constant feedback and then, through a module called „gulp-connect”, our production or development build is created and published on the local network the computer is connected to on a given port. This way we can instantly access the application from any kind of device by connecting to the IP of the computer the system is running on routed through the above mentioned port through a browser window. Besides broadcasting our application on a local network, our system was designed to autorefresh all the browser windows connected to it whenever a file change is detected.
Another job of our system is the running of tests on a custom Karma server, an process better described in the other contribution to the project as a whole.[8]
Last but not least, considering the fact that we were a team of two, it was mandatory for us to set up a common repository in order to allow pair programming and contributions to the project and allow us to do this regardless of the place or time it is done. Also, using a feature like this would help in keeping the code safe, well organised and have an editing history for easy restoration in case of an unwanted event which would lead to the project’s deterioration. The repository was removed after the completion of the development process since it was set as a public one in order to maintain security.
INTRODUCTION TO THE WEB AND USED TECHNOLOGIES
In this section we will take a look at the the basic principles the WEB lives around as well as the different technologies and frameworks used in our project.
(HTTP / HTTPS) Hypertext Transfer Protocol.
HTTP – HyperText Transfer Protocol.
Users of the World Wide Web are allowed by the HTTP set of standards to exchange information found on web pages. Entering http:// in front of the address when accessing any web page tells the browser to communicate over HTTP. As an example: http://www.utcn.ro is the URL for Computer Hope. HTTP in front of the URL is no longer needed in today’s browser since it has become the default communication method. It is kept in browsers, however, because of the requirement to separate such protocols as FTP.[1]
HTTPS – Hypertext Transfer Protocol over Secure.
HTTPS is a method of sending or accessing information across a web page in a secure manner. Before being sent, all data sent over HTTPS is encrypted. If intercepted, HTTPS prevents anyone from understanding the encrypted information. Because of the data being encrypted, HTTPS is slower than HTTP. For this reason HTTPS is used only on pages that contain sensitive information (ie. Online banking) or on web pages that require login type information.
(FTP) File Transfer Protocol.
FTP is a standard network protocol. This network protocol is used in accessing or transferring computer files that are located on servers computers over a network or Internet that is TCP based.
The structure.
FTP is built on a client-server architecture. This architecture uses separate data control and connections between the server and the client. FTP users can authenticate using a username and password (standard log in data). If the server configuration allows it the connection can also be made anonymously.[2]
(TCP/IP) Transmission Control Protocol/Internet Protocol.
TCP/IP is the basic protocol or communication language of the internet. It can also be used for private network communications. Like any other computer that sends messages to or gets information from, your computer is administered with a copy of the TCP/IP program when connected to a direct access to the internet.
The structure.
TCP/IP consists of two layers. Transmission Control Protocol, which is the higher layer, is responsible with the assembling of a file or message into smaller packets. These packets are going to be sent over the internet and received by a TCP layer that rearranges the packets to form the original message. Internet Protocol, which is the second layer, is the layer that handles the address part of every packet so that it arrives to the correct destination. Each gateway computer checks the address for the destination where the message should be forwarded. Some packets from the same messages could be routed differently than others. Even though, the packets will be reassembled at the destination.
TCP/IP uses the client/server model of communications. In this model a computer user requests a service and then it is provided that service by another computer in the network.[3]
(HTML) HyperText Markup Language.
Being the standard markup language, HTML is used to create web pages. HTML is composed of a series of short codes (tags that are enclosed in angle brackets) typed into a text-file by the web page creator.
The markup.
The HTML markup consists of multiple components like: data types based on characters; tags – including their attributes; references for character and entity. It is also an important component is the document type declaration. This type of declaration triggers the rendering mode.[]
The elements (also known as 'tags').
These elements, also known as tags, separate the HTML code from the normal text. Tags are represented by words that are written between angle brackets (ie. <word>). This allows the use of many different elements like tables, images, etc., by communicating to your browser what needs to be rendered on the web page. Different tags will achieve different functions. The tags themselves cannot be seen when you view the web page in a browser, but their effects are very much visible.
How does it work.
The text is saved as '.html' and viewed through a web browser (Google Chrome, Safari, Opera,Mozilla Firefox, Internet Explorer etc.). The browser reads the .html file and translates its HTML code into a visible form, delivering the page as the creator intended. If you wanted to create HTML web pages you would be free to use anything from a rudimentary text-editor to a powerful and capable graphical editor. Based on the semantics and syntaxes that are used
within an html file web browsers can render web pages from HTML code. Browsers use HTML tags and scripts for interpreting the content from the page, but do not show them. HTML is a markup language because it semantically describes the structure of a website along with presentation details, making it different from a programming language.
HTML allows the creation of interactive forms. Its elements are at the base of all websites. It also allows objects and images to be embedded on the website and it also provides ways of creating structured documents by denoting structural semantics for text such as links, lists, headings, quotes etc. Scripts written in JavaScript languages can also be embedded. This will affect the behaviour of the HTML webpage.
Also, web browsers can use Cascading Style Sheets (CSS) to define the design of texts and layouts.[4]
(CSS) Cascading Style Sheets.
CSS is a style sheet language that is used in describing the design and the formatting of documents written in HTML. It is most often used to change user interfaces and the style of web pages that are written in both HTML and XHTML. CSS is used by most websites to create user interfaces and webpages for applications, along with HTML and JavaScript, making it one of the most important technologies. CSS can be applied to any kind of XML document.
How does it work.
Primarily, CSS is used to separate the document presentation (elements such as the layout, fonts and colors) from the document content. This separation is mainly used to improve the accessibility of the content, provide more control and flexibility in the presentation characteristics specifications, enable numerous HTML pages to share formatting (specifying the relevant CSS in a different, separate .css file), and reduce repetition and complexity in the structural content. Before CSS rendering was made available, semantically insignificant tables were used in formatting pages. CSS made it possible to separate presentation instructions from the HTML content to a separate file or style section of the HTML file. It provides a list of formatting instructions for each matching HTML element. For example: a CSS rule specifies that "all heading 1 elements should be bold". It leaves a pure semantic HTML markup that asserts "this text is a level 1 heading" without formatting code (such as a <bold> tag) indicating how the text should be displayed.
This formatting and content separation makes it possible to present the same markup page in different styles for different rendering methods. These rendering methods can be on-screen, in print, and on tactile devices. Depending on the size of the screen or device on which it is being viewed it can also be used to differently display the web page. The author of a web page typically links to a CSS file within the markup file, but readers can specify a different style sheet (a CSS file stored on their own computer), overriding the one the author had specified. The default style of the browser used will be applied if the reader or the author did not link the document to a style sheet. The quick and easy apply of the aesthetic changes and graphic design of documents is another CSS advantage. It does this by editing a few number of lines in one file, rather than having to go through a long process of changing markup by crawling over every document line after line.
If more than one rule matches against an element in particular, the CSS specification describes a scheme of priority to determine the style rules that must apply. For the results to be foreseeable, priorities or weights are calculated and assigned to rules.
The syntax.
Using a number of English keywords to specify the names of style properties, CSS has a simple syntax.
A style sheet consists of a list of rules and each rule or rule-set consists of a declaration block and one or more selectors.
A declaration block consists of a list of declarations. These declarations are in braces. Itself, each declaration consists of a property, a colon (:), and a value. If there are multiple declarations in a block, a semi-colon (;) must be used to separate each declaration from the other.
CSS standard must be respected by properties. A set of possible values is attributed to each property. Some properties can apply only to particular groups of elements, while others affect any type of element.[5]
JavaScript.
JavaScript, or JS for short, is a dynamic programming language. JS is being classified as a prototype-based scripting language. It has first-class functions and dynamic typing. Because of this combination of features it makes it a multi-paradigm language. This language supports object-oriented, functional and imperative programming styles.
It is generally used inside of web browsers. The web browser implementations allow client-side scripts to interact with the user. They also allow the controlling of the browser, communicating asynchronously, and also altering the content of the document being displayed. JS is also being used in server-side network programming with runtime environments (such as Node.js), creation of desktop and mobile applications and video game development.
JS is also used in non web-based environments, such as desktop widgets, PDF documents and site-specific browsers. For the server-side web applications the popularity of JS increased with the apparition of newer and faster virtual platforms and machines. Even though JS was traditionally implemented as an interpreted language, for the client-side web browsers that are most recent use just-in-time compilation.
Having very different semantics, JS and Java are unrelated. The only similarities are the name and some standard libraries. While the semantics and design are influenced by the Self and Scheme languages, the syntax of JS is derived from C.
Features.
JavaScript supports most of the structured programming syntax of most programming languages like 'if' statements, 'for' loops, 'while/do while' loops, 'switch' etc. One partial exception is scoping. JS has function scoping (although, in JavaScript 1.7 block scoping using the let keyword was added). JS, like C, makes a distinction between statements and expressions. The automatic semicolon insertion, which allows the omission of the semicolon that would normally terminate a statement, is a syntactic difference from the C language.
Being almost entirely object-based, JS objects are associative arrays, augmented with prototypes. Object property names are string keys. They support both bracket notation (obj['x'] = 10) and dot notation (obj.x = 10). Properties and their values can be added, deleted, or changed at run-time. Most properties of an object can be enumerated using a 'for…in' loop. JS has a small number of built-in objects such as Date and Function.
JS includes an eval function. This function can execute statements provided as strings. It does this at run-time.
Run-time environment.
JavaScript typically relies on a run-time environment (ie. a Web browser)in order to provide objects and methods by which the environment can be interacted with scripts (ie. a webpage DOM). It relies also on the Web browsers provision of the ability to include/import scripts (ie. HTML <script> elements). It is common in most JavaScript implementations, but this is not a language feature.
Use in web pages.
Adding behaviour to client-side HTML pages, also known as Dynamic HTML (DHTML), is the most common use of JavaScript. Scripts are included from or embedded in from HTML pages interacting directly with the Document Object Model (DOM) of the page. Some examples of JS usage are:
Submitting data to the server or loading content from a new page via AJAX without needing to reload the page (ie. a social network might allow the user to post updates to statuses without having to leave the page, or to go through the menu items without having to refresh it (only by replacing the current content with the corresponding content)).
On the fly validation of input values of a form. This is made to make sure that they are acceptable before they are submitted to the server.
Interactive content (games for example) and displaying media content within the page.
Element configuration and animation (slide, resize etc.).
Browsing activities to numerous websites and transmitting information about the user's reading habits. This is frequently done by web pages for personalisation purposes, ad tracking or web analytics.
A JS engine (also known as JavaScript implementation or JavaScript interpreter) is an interpreter that executes the script accordingly by interpreting the JS source code.
Because JS code runs locally in a user’s web browser instead of running on a remote server, it makes the application more responsive because the browser can respond faster to the user’s actions. JS code can detect user actions that HTML code alone cannot (such as individual keystrokes). Applications like Gmail take advantage of this. Much of the logic behind the user-interface is written in JS code. JS dispatches requests for information (in this case the content of an e-mail) to the server. The wider trend of Ajax programming similarly better exploits this strength.
The most used host environment for JS is by far the web browser. In JS, typically, web browsers create "host objects" to represent the Document Object Model (DOM). Another common host environment is the web server. A JS web server would normally expose host objects representing HTTP response and request objects, which then a JS program could dynamically generate web pages by interrogating and manipulating these objets. Even though JS was never intended to be a target language for many frameworks in other languages, JS is the only language that has support for in the most popular browsers. The increasing speed of JavaScript engines has made the language a surprisingly feasible compilation target, despite the performance limitations inherent to its dynamic nature.[6][7]
PHP.
PHP is a general-purpose scripting language that is especially suited to server-side web development, in which case PHP generally runs on a web server. PHP runtime executes Any PHP code in a requested file to usually create dynamic images used or dynamic web page content on websites. It can also be used for client-side graphical user interface applications (GUI) and command-line scripting. PHP can be deployed on many platforms and operating systems, most web servers and can be used with relational database management systems (RDBMS). PHP is supported by most web hosting providers to be used by their clients. PHP is available for free, and the complete source code for users to build, customise and extend for their own use is provided by PHP Group.
Primarily, PHP acts as a filter, taking input from a stream or file containing PHP instructions and/or text and then outputting another data stream. Most output will be more commonly HTML, although it could be XML, JSON or binary data such as audio or image or formats.[8]
(CSS Framework) Bootstrap.
Bootstrap is an open-source, free tool collection for website creation and web applications. It contains HTML and CSS-based design templates for buttons, forms, typography, navigation and other interface components, as well as optional JS extensions. The aim for the bootstrap framework is to ease web development.
Bootstrap is a front end. It is an interface made for the user, unlike the server-side code that resides on the server or 'back end'. It is also a web application framework – a software framework which is designed to support the development of web applications and dynamic websites.
The Structure.
CSS Framework is modular and consists of a series of LESS stylesheets. These stylesheets implement the various components of the toolkit. A stylesheet called bootstrap less includes the components stylesheets. The Bootstrap file itself can be adapted by developers. This adaption is done by selecting the components they wish to use in their project.
To a limited extent, the adjustments are possible through a central configuration stylesheet. More profound changes are made possible by the LESS declarations.
The use of variables, operators and functions, nested selectors, as well as so-called mixins is allowed by LESS stylesheet language.
The configuration of Bootstrap also has a special "Customise" option in the documentation since version 2.0. Furthermore, the developer can choose on a form the desired components and he can adjust, if needed, various options values to their requirements. the pre-built CSS style sheet is already included in the subsequently generated package.
Grid system and responsive design comes standard with a grid layout of 1170 pixel wide. Rather, the developer can use a variable-width layout. The toolkit can make use of four variations of different resolutions and types of devices for both cases: mobile phones, landscape and portrait, PCs and tablets with high and low resolutions. Each of these four variations can adjust the width of the columns.
The set stylesheets provided by Bootstrap contribute with basic style definitions for all key HTML components. These provide a modern, uniform appearance for formatting text, form elements and tables.
Bootstrap contains other commonly used interface elements, in addition to the regular HTML elements. These elements include buttons with advanced features (ie. buttons with drop-down options or grouping of buttons, make and navigation lists, vertical and horizontal tabs, navigation, pagination, breadcrumb navigation etc.), advanced typographic capabilities, labels, thumbnails, a progress bar and warning messages. The components are implemented as CSS classes, which have to be applied to certain HTML elements in a page.
JavaScript components.
Bootstrap comes with several JS components. These components are in the form of jQuery plugins and provide additional user interface elements. These elements are such as tooltips, carousels and dialog boxes. These components in the form of jQuery plugins also extend the functionality of some existing interface elements (ie. an auto-complete function for input fields). The following JS plugins are supported in version 2.0: Modal, Scrollspy, Dropdown, Tooltip, Tab, Popover, Button, Alert, Collapse, Typeahead and Carousel.[9]
jQuery.
jQuery is a cross-platform JS library that is designed to simplify the client-side scripting of HTML. It is the most popular JS library today. jQuery is an open-source, free software licensed by MIT License.
At its core, jQuery is a Document Object Model (DOM) manipulation library. The DOM is a tree-structure representation of every element of a web page. jQuery makes finding, selecting, and/or manipulating these DOM elements convenient and simple. jQuery can be used to find an element, with a certain property, in the document (ie. every elements with an h1 tag), making it respond to an event (ie. a mouse click) or changing one or more attributes (ie. Visibility, color).
jQuery's syntax is designed to make it easier to develop Ajax applications, navigate a document, create animations, select DOM elements and handle events. Capabilities for developers to create plug-ins on top of the JavaScript library is also provided by jQuery. This allows developers to create abstractions for low-level animations and interaction, advanced effects and theme-able, high-level widgets. The creation of powerful dynamic web applications and pages is allowed by the modular approach to the jQuery library.
jQuery core features (DOM element selections, traversal and manipulation – enabled by its selector engine ('Sizzle' from version 1.3)) created a new 'programming style', blending DOM data structures and algorithms. The architecture of other JavaScript frameworks like YUI ver.3 and Dojo were influenced by this style, stimulating the creation of the standard Selectors API.[10]
Angular.js.
AngularJS is a structural framework for dynamic web apps. It allows you to extend HTML's syntax to express your application's components succinctly and clearly and allows you to use HTML as your template language. Angular's dependency injection and data binding eliminate a lot of the code you would normally have to write if not for AngularJS. Making it an ideal partner with any server technology, it all happens inside the browser.
If HTML would have been designed for applications it would have been the same as AngularJS. For static documents, HTML is a great declarative language. HTML does not contain many creating applications.
The impedance mismatch between static documents and dynamic applications is many times solved with:
Frameworks – a particular implementation of a web application, where your code fills in the details. The framework is in charge and it uses your code when it requires something specific. (ie. Durandal, Ember etc.)
A library – a functions collection which is handy when writing web applications. Your code is in charge and it uses the library when it requires to do so. (ie. jQuery).
AngularJS works in a different way. By creating new HTML constructs, it tries to minimise the impedance mismatch between what an application needs and document centric HTML. Through a construct called directives, AngularJS teaches the browser new syntax.
Client-side solution.
AngularJS is not alone in building the client-side of a web application. It handles all of the DOM and AJAX glue code you wrote and places it in a well-defined structure. This makes AngularJS assertive about how a Create, Read, Update, Delete (CRUD) application should be built. AngularJSs opinion is simply a starting point. It can easily be changed the way you want. AngularJS, straight out of the box, comes with the following:
-Everything needed to build a CRUD application in a cohesive set: Data-binding, form validation, basic templating directives, deep-linking, routing, dependency injection and reusable components.
-Testability story: End-To-End Testing, Unit-Testing, test harnesses and mocks.
-As a starting point, seed application with directory layout and test scripts.
AngularJS presents a higher level of abstraction to the developer simplifying the application development.Flexibility wise, it comes at a cost. Not every application is good for AngularJS. When AngularJS was built, it was built with the CRUD application in plan. Fortunately, the representation of the majority of web applications is CRUD applications. Understanding when an app is not a good fit for AngularJS means understanding what AngularJS is good at.
Examples of applications with tricky DOM manipulation are video games and GUI editors. These kinds of applications are different from CRUD applications. As a result they are presumably not good for AngularJS. In cases like these it may be better option to use jQuery, which uses a library with lower levels of abstraction.
Advantages.
Registering callbacks – it clutters your code, making it hard to see the bigger details. Removing callbacks is good because it can vastly reduce the ammount of JS coding you have to write, making it easier to observe what your application is doing.
Manipulating HTML DOM programmatically – is an important property of AJAX applications, but being cumbersome and prone to errors. By declaratively describing how the UI should change as your application state changes, you are freed from low-level DOM manipulation tasks. Most applications written with Angular never have to programmatically manipulate the DOM, although you can if you want to.
Marshaling data to and from the UI – the majority of the AJAX applications tasks are made up of CRUD operations. The flow of marshaling data from the server to an internal object to an HTML form creates a lot of boilerplate code. Marshaling data allows users to modify the form, display validation errors, validate the form and return an internal model back to the server. AngularJS has the ability to eliminate all of this boilerplate, leaving behind a clearer code without the the implementation details. What remains is a code that describes the overall flow of the application.
Not writing tons of initialization code – With AngularJS you can easily bootstrap your application with services, which are auto-implemented into your application in a Guice-like dependency-injection style unlike AJAX where typically you need to write a lot of code just to get a "Hello World" application.This allows you to quickly get started developing features. You fully get control over the process of initialization in automated tests, as a bonus.
When it comes to building UIs and wiring software components together AngularJS is built around the belief that declarative code is better than imperative code.[11]
PLANNING AND DESIGN
During this stage of the project the main focus was set on getting a clear idea about how the final product should look. In order to do this we have used multiple helper tools for wireframing, design help and, of course we had to pick a modern CSS framework since the scope of the project contained the building of a responsive web application. First we will take a look into how the visual design was created and after that, how the actual application structure was planned.
General presentation
First of all we had to think about the structure of the first page, what should be its elements and their priority in order to make a modern, interactive page and also to display the most relevant information on it.
We are only taking the first page in consideration as we put an extra effort towards the visual design consistency and managed to obtain an isomorphic overall feeling of all the pages. Also, this presentation does not include the material design and responsive design which will be covered in their own sections as they are highly complex and worthy of a separate explanation. Besides this, another important factor we have taken into consideration is the fact that the product owner should easily be able to edit the end product in terms of design, text and pictures so we centred our design towards achieving this.
In order to get a basic idea of how the final product would look and also have nice feedback sharing sessions between us as a team, we thought about the idea of creating the initial design through wireframes. This way we could achieve rapid prototyping and a good early overall idea of how to plan the application design and task sharing from an early stage of development.
The initial prototype and starting point for building the application was created towards the idea of getting a well established decision of how the homepage should look since this page should take the place of a so called dashboard of the project, the main component which links all the other ones together. In order to achieve this, as mentioned above, we wanted to make a graphical representation of it as a wireframe.
The firs design looked like this:
Next we will take a look at each physical component and explain the reasons and motives behind each decision we took along the planning stage of the application.
Coloring
One of the most important aspects we have found and researched about is the color theme which turned out to be one of the biggest players in providing a pleasant and intuitive user experience. Considering the above, we chose to go with the the university's main colors which are cherry-red and black and tweak them for each element towards becoming more suggestive for what each control of the application is used for.
After researching multiple similar applications (see Planning/Design chapter for more information about the research) and psychological factors of how the user experiences the application, the consistency of the color palette across the whole application plays a very important part in offering a fluid and sturdy experience. First, in order to achieve this, we needed a clear separation and classification of all the website controls which will be visible to the end-user and then decide exact colors for each of them.
The list of grouped elements is as follows:
Power elements: #BC171D – power red
Consisting of elements such as important headings, titles and icons.
Second order elements: #A12A1E – power maroon (darker red)
This category contains all the elements which are set to a second priority for the user's attention such as sub-headings, sub-titles, important sections of paragraphs..
Action elements: #C0392B – action red
These elements basically embrace all controls which can be interacted with by the user such as buttons, hyperlinks and so on.
Complementary elements: #E9E9E9 – dark gray (black replacement)
Consists of elements which require special attention or need highlighting and have a connection with the Power elements described above. Basically they are more design-intended to establish an equilibrium between the two basic colors. Also, the this is replacement for the black color we initially chose as it is was found as a better eye-candy and implied a softer, more friendly view for the overall application.
Main background: #FFFFFF
After choosing the above colors, a commonly contrasted color had to be picked to stand as the basic background color. As our power elements and complementary elements consists of darker colors, a white color was chosen for this.
Shadows: #D4D4D4
As our main background has the color of white, we figured we could add more depth to other elements by adding shadows, providing a more modern design. They are mainly used for most generic elements which needed an extra touch.
Disabled: #E4E4E4
After obtaining a basic color scheme for the project, having it even from the early stages of development turned out to be a great helper throughout the
whole implementation stage as a better feedback of the final product could be obtained easier and faster.
Logo
Keeping in mind the that the end product would be an university website we considered it's placing on the landing page an important factor for letting the user know they reached what they were searching for.
In order to obtain this, we chose to have it present across all pages, above the main header which will be described shortly, coupling the two as cross-application persistent items..
Navbar
The navigation bar is a core element of the project as it serves navigation from any state of the product towards any place inside the application. It serves as the glue between the whole project for the end-user and a friendly and intuitive companion while exploring the end-product. The design chosen for this was a really important decision as our application is a responsive one so it's display should provide the same suggestive user experience on a mobile device as well as on a desktop or notebook.
Main Slider
As a presenter of the landing page, a left-to-right navigation slider with information and links to all the relevant pages was added. This will be the container for dynamicly interchangeable content which allows the owner of the product to suggest important parts of the application for the user and should point towards those. It is certanly an attention catcher which makes the user participation in the decision making process when it comes to navigation very light.
Basically, the product owner has the ability to include any kind of HTML structure on the slides, including interactive content, videos and buttons. As an example, a slide could contain and display the most important pieces of information at a certain moment (registration period, exam's date, results of the simulation etc.). here we had some alternatives like rotating banner, carousel, slider etc.
As an example, at the moment of conclusion of exam results, a new slide could be added which would point to them and easily attract the user's attention towards this.
Informational Tiles
They serve the same purpose as the slider, but they are referring to more static content like general admission rules or other information which rarely changes and is most often of general interest.
These informational tiles have been designed to contain a suggestive picture, title, suggestive icon and linking button. All of the enumerated elements were projected so that the product owner can change them easily for reusability and fast editability.
News Section
This section is pretty straightforward as it always displays the 3 latest news to be added to the website. These elements consist of a heading, a paragraph and a bullet point picture. Again, just like the above elements, this area was designed for easy editing in the uture.
FAQ link and "Ask A Question" form
Again, as the research concluded, we found out that the addition of a easily visible FAQ section and questioning form specifically on the landing page would really help towards helping the aiding reach the information they are looking for not only quicker, but with much less frustration. Also, inviting the user to ask a question as straightforward as displaying a form for doing this directly on the landing page along with a friendly text, considering our targeted audience will be high-school graduates which are looking for making a decision towards their career provides a pleasant and ensuring user experience.
Contact footer
A commonly used practice in modern websites is the addition of a contact section in the footer of the page. As the footer element is persistent throughout the application, the end-users will find it easy to find contact information such as telephone numbers, fax numbers and social media pages of the institution.
Responsive design
Overview
First of all we will take a look into device usage statistics as this was a dominant factor in actually choosing to adopt a responsive design for the application. The usage statistic for general web access in the past few years has changed dramatically. As we are truly emerging into the informational era where this information is shared across most electronic devices through the world wide web, the evolution over the past years has been drastic, but not necessarily surprising.
We can clearly see a definitive overtake in 2014 of mobile users (mostly phones and tablets) over the traditional personal computer or notebook. This was the starting base of the motivation to integrating the application into a responsive design.
Also, another study showed the following statistics regarding information searches on websites such as the popular "http://www.google.com":
Creating a auto-restructuring website does not only turn it into a mobile phone friendly app, but also the the most important device categories presented in the illustration above which are PC/Laptop, Smartphone, Tablet, Games Console, Smart Tv. Basically the principle of "one size fits all" greatly increases the usability and accesibility of the website.
Also, a good question to be asked when building web applications is "What are users using mobile navigation for?". A good answer to this question was given by "Online Publishers Association/Frank N. Magid Associates".[18]
99.5% access content/information
63.1% access the Internet
62.1% check email
49.2% listen to music
46% play games
41.7% download and use apps
15% make purchases
15% read a book
Taking into consideration the facts presented above, adding the fact that the targeted audience will be of an average of 18-22 years old and considering our application will also stand as an informational resource which turned out to be the most common reason for general users to access the web through their mobile phones, after checking the last study there was no question about taking the decision of adopting a responsive design.
Bootstrap 3
In order to achieve what we talked about in the previous chapter, even during the design stage of our project we obviously needed to pick a CSS framework for obtaining the modern, responsive design and a provide good user experience as we initially planned. After a little research about what certain CSS frameworks provide, a breakdown comparison of them was needed. Most frameworks contained almost the same features so it was a hard pick but the choice was much easier after studying the documentations for a bit. After seeing the ammount of well established documentation pages and rich community support, the winner was picked mostly by popularity and was Twitter's Bootstrap 3.
One of the reasons we wanted to use a CSS framework even from the early stages of building the project was the fact that we wanted to have fast prototyping. Bootstrap offers this to be done as it's rich features and easy to understand structure were exactly what this project needed, allowing a big picture to be formed very early, easily.
The following lines will consist of the explanation some basic elements of the framework that were intensively used during the planning/design stage of the project. First of all, the grid system.
The grid system
This is definitely the most important component of every CSS framework as they consist of the building blocks of a website. Bootstrap excels at this, offering a large variety of options which fit our needs, even from the early stages of development.
A grid system is basically a way of organising content on a page, wether is it a mobile, a desktop device or a notebook on which the application is run on. This is essential since the project will support a responsive structure which basically means a 'one size fits all' design. This allowed us to create the pages for all the devices at once, even when starting up with the very first page. The system behind this consists of setting custom Bootstrap classes to the HTML elements by which the framework would know what element to show where on the page depending on the end-user's screen size, regardless of what device it is used on.
As an example, below we have some elements which have assigned a Bootstrap specific class which designate their place and width in the page:
For a better understanding on how the design was made with the help of the grid system and how it works, we can take a look at the following comparison between different viewports. This is exactly the way the project was designed by.
More details on the grid system and how we used it to fulfil our tasks will be covered during the "Implementation" chapter of the document.
Glyphicons
This package includes over 300 icons in font format from the Glyphicon Halflings set and ships freely with Bootstrap. This makes it easy to include small suggestive action-icons on the application which work great towards obtaining the material design which was proposed for the realisation of this project. Common places where these icons are set are buttons, list items, thumbnails, navigation elements and footer elements. Just like the grid system, in order to use them we need to add a class to a specific HTML element which is usually a <span> tag and the class assigned to it designates the icon to be shown. They look something like this, with the afferent class names:
Another micro-framework which was used for the same reason as the glyphicons is 'Font Awesome' which provides the exact same functionality as the glyphicons, providing a collection of even more icons.
Buttons and button groups / Navbar
Bootstrap provides great support for buttons, toolbars with buttons, nested dropdown buttons and so on, which are all part of modern web applications and match our material design, while providing a nice user experience. Also, as mentioned in the sub-chapter title, we also have navbars which support nesting of buttons. Not only they support this, but also they make them fit the responsive design by changing it's layout on a smaller device size. Also, handling dropdown buttons was essential for the scope of our project and Bootstrap offers a great toolbox for doing that. Below we can see an example of how the first implementation of our navbar looked like. These features were a great addition to our project's needs and more will be covered in the "implementation" stage of the application.
Forms / Form groups
Bootstrap's support for forms offers the developer a wide variety of options when designing how a form should look and behave. It enables the grouping and handling of multiple form elements in a controlled fashion and considering the fact that HTML forms are essential in any webpage, the help of this framework when using forms is good since it's support for them is very sturdy. It comes easy to disable, enable, switch, add new, remove new form input elements regardless of their type which is a great addition to this stage of the project.
Conclusion
After comparing different frameworks, the conclusion of picking Bootstrap was a real helper during the process of design of the project as it enabled fast prototyping since the first stages of design, allowing us to get a better view of how the final product should look, as well as early consulting on the project's requirements.
Practical usage
In order to describe how the design phase was actually done in terms of the decision making process of how things should initially look, considering the fact that our targeted devices are more than just a couple, a short overview of the prominent elements presented above in the "General presentation" section will be done while picturing them inside a small screen device such as a common smartphone and explaining how they were thought through.
Navbar
As mentioned before, the navigation bar is a very important component of the application so the experience of using it must be as good on a smaller device as it is on large screens. The solution applied in our case was to collapse and hide all the menu items into a single column and display them as rows which are shown when the user clicks the "hamburger" menu icon as seen in the picture below.
This way the navigation bar does not get overcrowded with multiple elements displayed at once, avoiding screen cluttering which is a factor that often induces users to avoid web pages with such design. Replacing all the independent menu items with a single interactive button with a suggesting icon for showing and hiding the menu items and keeping the university logo in the left end which acts as a home page hyperlink was the chosen way to deal with displaying this element on smaller screens.
Slider
The resolution for the slider’s design on a mobile device was pretty straightforward as all we needed to do was resize it to the targeted screen size and keep it in the same location. A nice to have feature which was though at at this stage of development was the implementation of controlling the slider by the swipe gestures which are available in all touchscreen devices.
Informational Tiles
A commonly used practice in responsive design of rearranging items which could be thought of as columns is to display them as rows since the aspect ratio is usually exactly opposite from a large screen device. This way it is much easier to display row elements on a screen size which has a greater height than width, just like it intuitively comes to do the opposite for screens with a greater width. Considering the fact that our tiles are grouped together elements and can be categorised as single items, we can simply flip them in a different arrangement altogether.
News Section
The same approach was taken as was for the informational tiles, only the news elements are a bit more complex in terms of block structure. This means that, besides rearranging them as whole news entries, the internal structure of each entry had to be redone. This concluded in a even better design for these elements in mobile view, causing the bullet point picture relative to each entry to be placed above the title and actual content. For a better understanding of how this was thought through, a wireframe representation which was made during the design phase can be viewed below:
Contact footer and FAQ Section
The footer section which contained two equally important sides was restructured by adding the social media icons on top of the other information for the simple fact that they take much less height space and are pretty self-explanatory and do not require extra information beside them.
The FAQ section was one of the elements which did not need restructuring for a different screen size as the display of elements consists of full width rows, taking up all the width of the page they need. So, in conclusion, maintaining the same top-down design as in desktop view was the way to go, the elements being able to spread across the full width of the device.
Material design
When it comes to building a responsive website we must think of a solution which solves the different problems which occur in terms of choosing the design style for our building blocks since the picked styles must fit the same purpose and have the same visual impact in different viewports. What this basically means is the fact that every piece of a page must have the same aspect on all the targeted devices and at the same time it must give the user the feeling of nativeness, the idea that what he sees looks like it was designed specifically for the device he is using the application through. This is when Material Design comes in. After researching multiple visual design patterns the conclusion that Google's Material Design principles and specifications would fit the scope of our project, especially since the documentation and examples are well defined.
There's not much to add to this in the planning stage of the project as applying the design style was done at the later stages of development which consisted of visual finishing touches so a more detailed explanation of how these principles were actually used can be found in the Implementation chapter of this project.
AngularJS
As said in the "Available/Used Technologies" chapter, we needed to pick a JS OOP framework for rendering the content directly on the client side, without any need for a server to process all the complex rendering techniques, therefore the separation of concerns and distribution of tasks takes place in a efficient and sustainable way and sustains a higher load of users / actions on the application.
After studying the pros, cons, limitations and powers of the most popular frameworks available on the web, the framework of choice came to be AngularJS.
Angular is basically what HTML would have been, if it would have been created for developing applications. HTML is a good declarative language for documents but it does not contain much when it comes to creating applications and as a result we have to do lots of workarounds and 'hacks' in order to obtain the wanted results of a dynamic web application.
This framework does not stand by itself in the process of building the client-side of a web application. It handles all of the DOM and AJAX code and puts it in a well-defined structure. This fact makes Angular know about how a CRUD (Create, Read, Update, Delete) application should be constructed. But while it is opinionated, it also makes sure that this is just a starting point which you can change without much hardship. Angular comes with the following features out of the box:
– Data-binding, basic templating directives, form validation, routing, deep-linking, reusable components and dependency injection.
– Testability story: Unit-testing, end-to-end testing, mocks and test fixtures.
Angular takes a different approach on this by attempting to minimise the differences between document centric HTML and what an application needs by combining the two together. Angular creates custom HTML elements called 'directives', enabling the browser to understand custom tasks and entities, which is a core feature of our framework of choice.
Considering the fact that the project target is building a highly dynamic, modern-looking, responsive and efficient web application, the conclusion that the features of AngularJS would be the best for the scope of this project.
Some of the functionalities available and used in the application are:
Two-way data binding denoted with "{{}}".
DOM control structures for repeating, showing and hiding DOM fragments.
Support for forms and form validation.
Attaching new behaviour to DOM elements, such as DOM event handling.
Grouping of HTML into reusable components.
Angular is built around the concept that declarative code is better than imperative code when it comes to building UIs and wiring software components together.
It is a very good idea to decouple DOM manipulation from app logic. This dramatically improves the testability, reusability of the code and makes it easier to scale.
It is an excellent idea to separate the client side of an app from the server side. This allows the work to run in parallel, and allows for reuse of both sides.
It is very helpful indeed if the framework is aware of the whole process of development: From designing the UI to writing the business logic and back to testing.
It makes writing easy tasks trivial and conceiving complicated seeming solutions possible.
Angular frees you from the following downsides of other frameworks:
Registering callbacks: Registering callbacks makes your code grow, making it hard to what really matters in your code. Removing common code such as callbacks is a good thing. It vastly reduces the ammount of coding you have to do, and it makes it more easy to observe what your application does.
Manipulating the DOM programmatically: Manipulating HTML DOM is a main activity of AJAX applications, but it's not error proof. Most applications written with Angular never have to change the DOM, although you can if you want to.
Writing tons of initialization code just to get started. You basically get away with little code in order to kickstart your first Angular application, which makes it easy to get to the point and get there fast.
All of the features mentioned above fit and cover the scope of our project, justifying our choice as a fit for this project.
Moving over from describing why we chose this as our JavaScript framework, in the following section we will be describing what certain components of this framework are particulary used in this project's application.
Views
The views of a webpage are practically the routes, the pages themselves. Angular allows, through it's rich gallery of modules, lots of routing options, one of which being the "angular-ui-router" component. This allows us to separate our views into a concept named "states". These states represent, as the name suggest, actual modes of the application. For example, if a application is in the "home" state, this would mean that the page should be pointing to the homepage. Besides this, this module also allows nesting states which is greatly useful in single page applications, enabling the developer to have full control over what the user should and should not see at a certain point.
For routing and connecting our pages together, there were states and sub-states declared for each and every bit of the application.
A diagram of the basic flow throughout our application would look something like the following.
Also, in order to understand how substates work in our application, we can think of a page which needs or needs not to contain a custom element. If the page should contain the custom element, we can create a substate of the page's original state which tells the application that the custom element should be build. This would look something like this:
This was a deal closer for our choice of framework as this is one of the best tools available to create a scalable, complex and especially stable application. The best example of using this and choosing this in our designs would be the Faculty -> Domain specific pages.
We would implement the faculties as base states, and the domains of those faculties as the faculties' substates. So, for example if we have the "Automation and Computer Science" denoted as the |ac| state, we would have the department of "System Engineering" under the substate name of |ac.systemEng|.
As a conclusion for the views section, even since the design state of the application, choosing "angular-ui-router" as our page management system was a clear shot.
Values in the view
One of the creates powers of AngularJS is the two-way data binding which is better explained in the "Technologies" chapter.
What this basically does, is the linking between the view value and the model value of our objects. An easy representation of this would look like so:
So, for example if there was an action which would trigger the change of the model, the view would be updated right away and the same goes the other way around, in the case of the view value updating which would trigger the model update.
This was another extremely convenient feature which the framework provides considering the fact that the application would have to show lots of different dynamic data based on what the user wants to see, generating a fast and responsive feedback from the application to the user, as well as a good user experience.
When we are actually using this feature, what is basically done is a connection between all the dynamic data we want to show in the view and the models inside our application. For showing a value in the view, the value must be embraced by curly braces and needs to be present in the current working namespace.
All the communication between the model and view described above is done through the $scope property of the designated controller which controls a certain part of an application which will be reviewed shortly.
Controllers
In Angular, a Controller is a JavaScript constructor function that is used to augment the Angular Scope.
When a controller is added to the DOM the framework will instantiate a new Controller object, using the specified Controller's builder function. A new scope will be available as an injectable parameter to the Controller's constructor function as $scope.
In the application, we designated a controller for each page and another one for each sub-page. And by page and sub-page we can now relate to as states and sub-states. Every state and sub-state has it's own controller so we can clearly separate the concerns of the application. This approach was chosen in order to have all the parts of the app's functionality covered by a specific component and also helped in keeping the code clean, tidy and separated.
An example of a user action which affects the $scope values which get reflected in the view would look like the following:
Dependency injection
Dependency Injection (DI) is a software design pattern that takes care of including certain application components into others and making it possible to do so. The Angular $injector service is in charge of creating modules, resolving their dependencies, and providing them to other components when needed.
The reason this was used in the project was the fact that you can very easily inject data across the application, from any place to any place just by encapsulating a certain functionality in a service. Services are split into factories and providers, functionalities which are better explained in the "Technologies" chapter.
By using dependency injection we can easily separate and modularize concepts, concerns and functionalities into modules and include them wherever they are needed. This is a great design pattern as it is highly potent for scalability and separation of application tasks.
Forms
Angular provides a great web form support which makes it easy to validate, handle and control forms.
Forms provide validation services, so the end-user can be aware of invalid input values before submitting a form. This provides a better user experience than server-side validation alone because the user receives almost instant feedback on how to correct an error.
In this project, the Angular forms were used for the "Ask a question", "Exam sign-up" and "Simulation sign-up" forms which will be thoroughly detailed in the "Implementation" chapter.
Directives
Directives are properties on a DOM element (such as an attribute, element name, comment or CSS class) that tell AngularJS's HTML compiler to dispatch a specified behaviour to that DOM element or even transform the DOM element and its children.
They are the building blocks of an Angular application and are used throughout are application intensively for taking care of many different tasks such as repeating elements in lists, filtering content, data binding and so on. This was a very helpful feature which was found as a perfect match for constructing this project bit by bit.
Overview
Considering all the features of the framework presented and the use-cases of them in our application, Angular was a clear winner when picking our JS framework. It provides great tools and a good documentation in order to complete the design phase of a project fast and efficiently. The separation of concerns is clear and manageable even from the early stages of the project, thus providing us with a rich set of tools in order to create a sturdy and well established application structure, encapsulate functionalities within separated injectable modules and have it separated into states which control certain, easy to set parts of the application.
BOOTSTRAP IMPLEMENTATION
In order to present how every important component of our application was implemented design wise we will categorise these components by roles and functionalities and have an in-depth discussion about how the framework was actually used towards building and obtaining the final look of the project. The main subject will be the landing page as it contains most of the elements found across the application, but the equally important pieces which provide significant functionality will also be covered.
NOTE: The first few elements will be presented with a bit more code examples for easier understanding as both HTML and CSS are descriptive languages and Bootstrap is controlled strictly by the two.
The persistent header and footer
The first and most important aspect about this section is the fact that the header and footer elements are exactly the same and have the exact same location on any page of the application because of the dynamically changing content which only happens between the two, as mentioned in the technological explanation of AngularJS.
The Header
As the actual implementation of it's looks is a bit complicated and requires an description of how every single Bootstrap CSS class works, an explanation based on the actual HTML code of the navbar will be done.
As can be clearly seen, the way of telling our framework we want to build a navbar is by fisrstly inserting a <nav> element with the class "navbar navbar-default" which instantiates a basic area for adding navbar elements.
(1) – By adding the "navbar-header" we declare a namespace for inserting content displayed on the header in mobile view, but also allows us to add the navbar logo.
(2) – A <button> element was added with the class of "navbar-toggle collapsed" which represents the "hamburger icon" of the button which toggles the links on and off in mobile view and to connect the button to the actual functionality, we added a custom attribute of data-toggle="collapse" which tells the framework the fact that we want to use that button for collapsing the menu.
(3) – The "navbar-brand" class added to a anchor element transforms it into a logo container for a small icon which will be displayed in both mobile and desktop views as a basic <img> item with a :src: attribute.
(4) – This tag was implemented as the container of the other elements of the navigation bar which basically consist of linking buttons in our case. By adding the class of "collapse navbar-collapse" we enable the framework to treat them both in mobile and desktop view under the same code.
(5) – Every <li> element consists of one single navbar entry. In our case in which we wanted to create links, we simply implemented an anchor tag inside them which contained only the text to be displayed. Notice that the :href: attribute is not linking to anywhere and that is because of the fact that our application routes are controlled throught states which will be better explained in the javascript framework implementation section.
(6) – Some of the buttons in our navbar required a drop-down functionality to enlist several links relevant to the button clicked. In order to implement this, it was needed to add a <li> element with the class of "dropdown" which enables Bootstrap to accept another list of items inside the current list.
(7) – Now, an anchor tag with the class of "dropdown-toggle" must be added and also given a :data-toggle: just as mentioned for the (2) element before, but this time in order to control the framework towards opening a dropdown menu, we must assign it the "dropdown" value. Also, in order to add a downward facing arrow to suggest to the user the fact that it is a dropdown list, we used the framework's glyphicons functionality which easily allowed us to add a caret icon by inserting a <span> element with a class of "caret". For a better understanding, the way these glyphicons work is described in the technological description part of this paper.
(8) – Lastly, the implementation of the dropdown list buttons had to be achieved so, as suggestive as it looks, in order to enable a basic dropdown list to be activated by the framework, we needed to add another <ul> element which again consists of <li> elements which describe the content and pointers of the item.
The Footer
We will be taking the same approach in presenting the footer's implementation, by organising a discussion about how each element was defined and how the final result looks.
First, we can see that our code is wrapped in a <section> tag. This is a good practice towards organising page elements together which can, this way, easily be reused or identified. This is a common practice we implemented throughout our application. Also, we wrapped the actual content of the footer in a <div> with a class of wrapper which serves as a helper for the developers when future updates may arise so that styling of multiple elements can be easy, but also as a visual aid and is in concordance with the W3C best practices of wrapping multiple similar elements inside a <div> tag. Before presenting what the highlighted lines of implementation actually do, we will take a look at the rendered product and map each input to a result.
(1) (2) – This is the first time during the implementation process we encounter the usage of the grid system. As described in the earlier sections of the paper, the framework splits it's view into 12 columns and allows the developer to assign CSS classes to elements in order to distribute them throughout the grid. In order to implement the design shown in the planning stage of the project, it was needed to create two columns with the second having half of the width of the first. Considering this and the fact that we needed to split them into 12 separate blocks in the grid, the obvious result was a column of width 8 and a column of width 4. With the obtained values, what was left to be done was the attribution of certain classes to the wrapper elements which turned out to be "col-md-4" and "col-md-8". The "md" out of the class name represents layout display for MEDIUM screen devices. What this basically means is that for screen sizes from medium to large, this type of layout will be used. For smaller screen sizes such as "sm" (small) or "xs" (extra small), each column transforms into a full width one, transforming them practically in rows which in our case is exactly what we wanted.
(3) – The block display type elements were used since we also wanted these items one per line so, considering that <div> elements have this by default, we injected the content inside them.
(4) – Similar to the Bootstrap Glyphicons, another micro-framework called "Font Awesome" was mentioned previously which has just this functionality but with a larger set of icons. This works the same as the normal Glyphicons, only require a bit different formatting which is a <i> element with the class of the name of the icon as seen above.
Basically by using the grid system and setting grid widths for the two main components of the footer, the problem of displaying the content of the footer across all device sizes from mobile display to a large screen TV was solved easily.
The persistent header and footer
This element, as the name says, is the container of all our content on every page. Every single piece of dynamic data and elements are going to be placed inside a few nested <div> elements which will have certain properties assigned to them which render the information's appearance. This is the first order child of the application's ng-view set between the header and the footer. This consists of a white background 1200 pixel fixed width box with a drop shadow over a grey background which was added for an effect of visual depth. The content container is actually a two-piece element since each of the two serves a different purpose, but together they create the element described above.
The parent box is the element which defines the size and position of the whole container and is denoted as a <div> with a custom created class of "fixed_12" which enforces two CSS rules. The first rule is set for ensuring the fixed 1200 pixel width which we were talking about ("max-width: 1200") and the second one grants the centred positioning on any screen size through the commonly used CSS solution of setting an automatic margin in all sides ("margin: auto"). The second box which was mentioned above consists displaying the styles associated with itself through the custom class named "main-container". The styles ensure a slight border ("border: 1px solid #E9E9E9") and a drop-shadow which, the same the reason for which it is used in all the other places in our application, creates the effect of depth. This kind of container is an important one since a great aspect in single page applications is the fact that it creates the illusion that the page never changes, only the content inside it does. So using the exact same content container for any kind of content we would like to display ensures conistency across the views and fits the current design.
The Slider
In terms of cross-application rules, the front page slider is the only piece of content which defies the general rule of a maximum 1200 pixel width. The only reasons this was done this way was as for eye candy and targeted marketing. Making an element stand out from the rest of the page draws attention and considering that the product owner may want to put an extra emphasis on certain information across the website, the slider was a good place to put a connection to that information in. The way this was implemented was simply by not including it in the main content container described above, but placing it exactly above it with it's own styles. The way of displaying it at the full with of the page was by adding the "width: 100%" CSS rule.
Informational Tiles
As the wireframes describe which were done in the planning part of this project, an implementation of 3 equal in size info-boxes was needed. The same grid system techniques were used for obtaining that result just as used before.
The basic structure consists of 3 <div> items wrapped by a <section> container. First, we needed to ensure that the 3 elements together took 100% of our 1200 pixel fixed width so we ensured spreading them equally across the grid system by adding the class of "col-md-4" to each of them, resulting in fully filling Bootstrap's 12 grid blocks limit. Also, a class of "promo-tile" and a class of "tile-x" where 'x' stands for the index of the tile was added to every div element so that general and individual common CSS rules could easily be added.
Next, taking a look into what actually lives inside the tile containers we were talking about, the HTML structure looks something like the following:
In order to better explain how the implementation of this was thought, we explain the purpose of each highlighted element by one.
(1) – The main container of the tile's content. It is the element by which the background picture is set. A really important part of the implementation of a responsive website is the integration method of images as different screen sizes display images differently based on resolution, position and other similar factors. The best way which was found of implementing this was a scalable, reusable and replaceable one. This implementation does not consist of using a classic <img> tag as images usually get displayed on the web, but setting the image as the background of a container which has the size you the image you want to display. By enforcing a couple of styles which are ("background-size: cover; background-position: center;") the browser always needs to calculate the image position on a screen resize event. The screen resize event triggers not only when the screen resizes, as the name suggest, but also on the first page load. This way we ensure that the images get displayed correctly wether the user is using a mobile device or a desktop, wether the aspect ratio of the boxes change across devices or wether the actual size of the boxes would change at some point for some reason. The browser will know how to rescale and get the most out of the declared image.
(2) (3) – This is the circle icon element which is present on top of every promo-tile which consists of a circle drawn purely through css by defining a border-radius of half the container's size and by inserting a suggestive "FontAwesome" icon in it's center.
(4) (5) – This was implemented to contain half of the tile's space and include a semi-opaque white square which would serve as a background for the promo text (5) in order to ensure readability whatever the background picture may be. This was done by defining a <div> element with half the height of the tile and with a white background using the 'rgba' css rule enforcer which allows the creation of a color and also specifying it's alpha factor: "rgba(225, 225, 225, 0.5)".
(6) – Lastly, an addition of a button wrapped in a anchor tag was made which would point to the source of the information displayed on the tile. Notice the "btn-default" class on the <button> element which sets the button's style to one of Bootstrap's default rules but which was overwritten in our own CSS files in order to tweak some parts of it such as color and corner roundness.
The final result to which we coud compare the code to looks like this:
News section
The news section implementation was a trickier one in terms of consistency across devices but after several rethinks in the planning part, a conclusion with a valid cross-device arrangement was found. We will take a look at the basic implemented structure of a single news entry to get a general idea of how they will look alltogether.
(1) – The main container of the whole news item, as the CSS class "news-item" suggests. This contains the basic styling of the whole container and glues the other elements together into a single box.
(2) – The two sibling level <div> elements are the containers for the bullet point image and the text content of the news item. The Bootstrap classes of "col-md-3" and "col-md-9" ensure a 1:3 ratio across the full width of the common main container and also, like the elements presented before, enforce the vertical stacking of the two in mobile view which is convenient.
(4) – The container of the actual text content which consists of a <div> with the class of "article" which groups the title and paragraph together. The header and paragraph are styled accordingly with basic CSS rules.
FAQ Form
The implementation of this section was done exactly as the elements before it, the only difference being the fact that all the elements have their own full width column and do not need extra attention for other screen sizes as an element per column will fit even the smallest display.
Conclusion
The implementation of the elements present on the landing page greatly reduced the effort of creating new pages as the HTML and CSS structure was done as a reusable one. This basically means that we could reuse all the custom created CSS classes or HTML elements as on the front page all across our application and, because as mentioned before, the two languages are descriptive ones, this means that the reuse of the HTML code draws the exact same CSS styles on any page as it did on the home page, rendering itself consistently, correctly and, of course, exactly the way we defined them earlier.
ANGULAR IMPLEMENTATION
As it is has already been reminded, the framework of choice for rendering content for our users and handling the business logic behind our application is going to be AngularJS. In this chapter we will be taking a look at the implementation of the main components of the website, as well as cover routing, states, internal architecture design and RESTful requests management.
Overview and basic architecture
Design Pattern
As we already know, AngularJS is a framework which works under the MVC (Model – View – Controller) pattern. This means that our application's components must be split into Models, Views and Controllers. The separation was made by grouping functionalities into one of the three mentioned above concepts. What this basically means is that bussiness logic, model-view connections and internal framework logic were stored in *Controllers*, the hardcoded data, CRUD operations and the model state were stored in *Models* which in Angular are split between services, factories and providers and finally, the actual HTML files which contain placeholders, directives and a part of rendering logic into *Views*. All this aside, before taking a deep dive into how every component is defined as one of the three, the project's structure had to be defined.
Directory Structure
The chosen implementation type for our source tree is functionality based as compared to the traditional component based one. This means that we will have all of our JS and HTML files grouped into directories which reflect a certain page, a certain state in the application or describe a certain task that they are supposed to do. This was found as a better pattern than the classic one which stated splitting our app into abstract components folders such as "controllers / models / resources / etc." because of the fact that when it comes to scalability, the complexity and the number of files in a project grows and by adopting this technique, navigating through the project and trying to find a specific component is much easier for the developers and even for future contributors which may work on the project.
The application as a whole is located under the 'src' folder which, at the first level of separation holds all the basic directories for all the basic file types used in such applications. (1)
Next, besides our usual assets such as images or CSS files, the actual AngularJS application lives inside the "js" and "views" folders. As can clearly be seen, the directory tree is exactly identical inside the two (2) because, as said earlier, we want to make it easy to find and control whichever component a developer may want to. Taking a look into them reveals the fact that every piece of functionality was implemented in it's own folder such as "despre" which stands for the "About Us" page or "facultati" which is the controller for the "Faculties" page. This way our files will have only one single task and bugs or error detection process can be much less time consuming. The only folder which breaks this pattern, but with a good reason, is the "common" folder. (3) The motive behind this is that the reusable components or, as the name says, common components which are used over multiple files will be stored here to avoid redundancy and duplicate code across our project. What this basically enables is the powerful use of Angular's build in dependency injection system of which reasons and advantages will be covered shortly in this chapter.
Helper Files
For running the application under the Gulp.js continuous integration system we have build, we have added a few tasks and files which come in the aid of the development process. One of these files is the ".jshintrc" file in which we have a well established set of rules for a custom code linting in order to aid in keeping code structure and standards consistency in all JS files of our project. Also, by using a Sublime Text plugin called "TodoReview" we have created a system for connecting a common todos list in the root directory of our app called "todo.todo" which is controlled by the Git versioning system so the file stays the same for all developers working on the project in order to keep track of the current implementation stage of the whole project, but also about the next features we want to add at a certain point and in what order should they be added. Besides the files mentioned above, we also have a "bower.json" and "package.json" declarative files by which the package managers used in this project "Bower" and "NPM" read, maintain and update the required development and production dependencies needed for our project. A better explanation about the helper files mentioned above and how they work can be found in Raul Dolha's contribution to the project as a whole.[8]
Architecture
In order to describe the architecture of the application as a whole, a series of helper AngularJS design graphs will be presented. First, we will take a look at the basic legend of what each color and shape means when attributed to a diagram object means and then we will take a dive into the actual relationships between them.
First, as Angular works with modules and we have separated our application between multiple modules, their implementation and architecture was pretty straight forward. Each module consisted of the javascript files coupled with templates of each specific page or functionality. Also, we may see the related external modules we used as „plugins” for our application. The diagram looks as follows:
Some of the simpler modules which do not cover much functionality but do deserve to have their tasks separated from the others have a very basic implementation. Basically, they only contain the injected items and the module definition which are both used for creating a controller to be used towards handling the logic associated with a specific page. A good example of such a module would be the „app.contact” module.
Other modules contain more items and may have more controllers attributed to them since they cover a wider range of duties and manage connections between them. For example, in our admission enrolment page which has the functionality covered by the „app.inscriere” module, we can see how multiple factories can get injected into different controllers and also how a module may hold more than just one controller.
Lastly, in order to present how the application joins all the modules together and works as a system which is controlling and managing them we can view the module diagram at the application’s main module level called „app”. Here we can see some of the modules presented above being included as dependencies to the main module and how they all get connected together.
Basic Routes and States Management
One of the initial steps of implementing a single page application is the separation of the so called pages into symbolic routes so that, even if the application only displays content on a single page which remains the same until the user takes any action, it will be possible to reach a certain state, however deep or complex it may be through the URL link set to a certain state. In order to use this functionality we needed to override Angular's basic $routeProvider service with a custom, community created one called "UI Router". What this does, is that the classic route management system is put aside and allows us to use the custom one instead by specifying "ui.router" as a dependency of our project. Also a very important note is the fact that all the templating code set for a specific state will be placed only inside the element with the attribute of "ui-view" of our main "index.html" file which is basically where all the dynamic state switching happens. Our states declarations are spread across all our .js files of our project instead of having them all in one place. This makes it easy to reach the declaration of a certain route quickly as it's instantiation and name is exactly the same as the file it is located in.
Implementation
As said earlier, the place of declaration of each state takes place inside the state's .js file which is located under the folder with the same name so, for example after we defined the state for our Contact page it looked something like this:
The instantiation of a state must be done in the config phase of the project which is located in the callback function associated with the "config" method called on our application module. First, we need to inject the new $stateProvider service into the config phase (1) by specifying it as a callback parameter to the function itself and making it available inside this namespace. Afterwards, in order to declare our state we use the "state" method (2) which takes two arguments, the first being a string which represents the name of the state and which will be used as a handler to reach the state itself and an configuration object in which we specified a few extra options. The first parameter called "url" (3) is where we specify the route to be associated with the state "/contact" so the full route to this page looks like the following:
Next we must define the template to be used to render the page (4) "views/contact/contact.html" which is, as said earlier, mirrored by the .js file we are writing the code in with the same name located at "js/contact/contact.js". Lastly we mentioned the name of the controller to be used during the process of rendering the page and of handling the user interactions with the page's content (5) which in our case is "ContactCtrl".
This being implemented, now we can simply navigate to this page by one of the two ways of changing a state. The first method allows controlling states directly from the HTML and is done by adding a "ui-sref" attribute to a HTML button or anchor tag which has the name of the state as the value. The second method allows us to point the browser to a certain state by calling the "go" method on the $state object and, as opposed to the first method, this must be used inside the javascript files.
Usage
By having defined our application endpoints as states, as mentioned above we can use one of the two methods of switching the application's state from any to any. A few places we have used the HTML notation would be in the navbar buttons, the informational tiles buttons and basically to any other physical link on the page since it is the basic way to have a user interaction trigger this event.
The second method was used in places in which we wanted to enforce a certain state straight from the javascript code whenever a specified event occurred. For example, during the bootstraping process of our application the initial view "index.html" is instantiated which only contains the basic template and, as mentioned at the beginning of the chapter, considering the fact that the dynamic state swicthing takes place inside the element with the "ui-view" we need to tell the application what is the state that the process of starting up the application should default to. This was done by adding "$state.go('home');" as the first line of our main application controller "AppCtrl" defined with the "ng-controller" notation inside the HTML of the index file of our project. What this does is that as soon as the application is instantiated and the basic view is displayed for the user, the fist action to take place is the switching of the application state to the "home" state which contains the landing page content.
NOTE: As a safety feature in the case of a user accessing an inexistent route in our application manually we configured it to default to the homepage as well by using the "otherwise" method in the config phase of the main module. It's usage is exactly the same as the "go" method described above. "$state.otherwise('home')".
Factories as Models
The concept
At an architectural level the models of our application basically consisted of objects which did not reflect their state in a view as most of the CRUD operations done are done through POST requests, so basically creating and updating items inside the database. For us this meant implementing them as Factories. Doing so allows us to use the power of dependency injection available inside our framework so this would be a good moment to talk about this.
DI (Dependency Injection)
It was concluded that the concept of dependency injection is a great and powerful tool available for use in our project and what it basically allows us to do is to physically inject any piece of code defined in a certain way (in our case, as a Factory) by specifying it's definition name as a callback parameter to any callback function besides the ones inside the config phase of the application's bootstrapping process. The implementation of the factories will be discussed in the next sub-chapter but the use of them and the actual injection of it into a controller looks something like this:
The list of function parameters seen above is actually a list of dependencies we want to inject.This consists of tools, built in services and custom made factories we want to use inside our controller. In our example we are taking a look at the "InscriereExamenCtrl" which is the controller used for managing exam submissions of our website and through the injected parameters we have 3 custom items "config" which was declared by the type of "Value" and, the ones which are more important to us during the scope of this chapter "Countries" and "Licee". What this basically means is that we will have access to what our two factories return and those are a list of countries and an object which consists list of high-schools mapped by city and country.
So, simply by adding the wanted parameters to a callback function anywhere inside our application, we have access to the data they are set to provide.
Implementation
The actual implementation of the factories is pretty simple and straightforward. We will take the examples mentioned above, "Licee" and "Countries" and explain the implementation of each of them. The only thing we want to achieve through those factories is the action of accessing some sets of data which will then be used inside our controller's business logic. The content is static and does not change so a static factory for each was created. By simply calling the "factory" method on our app's main module called "app", we have access to a callback in which we may return the values we need. As for the other similar methods to this one, it’s constructor is relatively similar as the factory's name is defined as the first parameter of the function and on the first line inside our callback function we are only returning the objects we want which are hardcoded inside our factory's definition. Their usage and operations are not defined here as the only task we want our factories to do is the retrieving of these values.about this.
Controllers
Overview
At an architectural level the models of our application basically consisted of objects which did not reflect their state in a view as most of the CRUD operations done are done through POST requests, so basically creating and updating items inside the database. For us this meant implementing them as Factories. Doing so allows us to use the power of dependency injection available inside our framework so this would be a good moment to talk about this.
Basic Controllers
First, we will take a look at the implementation of some of the more basic controllers to get an overall idea of how they work in our project. For example, in the case of the controller for the "Contact Us" page which is only displaying a map besides some static content.
The definition of a controller is similar to the definition of all the other components previously discussed, by calling the controller method on our application module and giving it a name as the first parameter. Then, inside the callback function we included an implementation of a Google map using the "Google Maps JavaScript API v3" service. As can be seen, the only activity going on inside this controller and thus on the page that user sees is the definition of the method which takes care of instatiating the map in a designated container, and the function call so we make sure that the map gets shown as soon as the controller is up and running at the same time as the page gets initialized.
Complex Controllers
Even though some of the pages do not require complicated logic and multiple event handler bindings or page-to-controller connections, the real power of Angular's controllers and the $scope object is much more obvious in complex situations. In order to describe the implementation of one of our more complex controllers, a comparison between the Controller code and it's result in the Views will be made.
First of all, we will be describing what was actually implemented inside the controller's definition. All the values we will want to show in the view must be set on the $scope object so the view has access to them. What this means is that through the first lines of the controller (1) a property with a suggestive name was set on the $scope for every value that was needed to be displayed inside the view. Besides the values set for display we also declared a few helper values which would let the view know what it should render such as "$scope.globalShow" which would be set to true at the last stage of completeing the form for the user to be able to confirm his entered data or "$scope.triggeredErrors" which is a value by which we can manually trigger the visibility of the form errors on or off. Also, a very similar task was set to "$scope.pageInputs" and "$scope.pageTitles" (2) but in this case they were attributed more complex objects which will make more sense when presenting the view part too. Next, since our form will be a multiple-step one, we have added a method on the $scope (3) object for changing the page forward and backward by specifying a boolean parameter which lets it know which way it should go. Lastly, we have a custom asynchronous implementation for an AJAX form submission since we do not rely on our backend to render our response page since we do all the view handling inside our framework and want to display the results dynamically without ever changing the page. Our basic view implementation which is managed by the controller presented above results in the following form:
Now that a general idea of how this controller is composed of was made, a representation of how the view logic handles the $scope properties will sort out the connection between the two.
We wanted to display the current state of the form to the user and our form has basically two states: "in progress" or "confirmation page". The showing of one of the two messages fit for each of the states is decided by the "ng-if" directive which takes a javascript expression as a parameter and after evaluating it decides if it should show the element it was set on or not depending on wether the evaluated expression returns a value of TRUE or FALSE. This way, when the "$scope.globalShow" value is set to TRUE, the message "Confirmare date" will appear on the screen. When it is set to false, the other message will be displayed which states the current progress of the form completion process. Looking inside the first <span> element reveals the "{{}}" notation which was described in the introduction of this project as a two way binding expression evaluator. This basically means that whatever value we place in there, if it is present on the scope it will be shown in the view.
Also, another example would be the implementation of the error messages like the ones above for the "E-mail" field. We can see the two errors "Camp obligatoriu." and "Email invalid." which get displayed depending on the set of rules we decide. The rendering of one of the two is done by implementing a condition inside the "ng-show" directive which works similar to "ng-if", only this one does not completely remove the element from the page, it only hides it with the CSS rule of "display: none". An angular form stores it's errors in the form object model under the "$error" property so basically we are showing one of the two errors wether one of the two errors may have occurred on this specific field. The implementation of the other input fields of the form is very similar to this one, each taking into account it's own restrictions and errors.
Lastly, the lower part of the template was implemented in a way that that the displaying conditions of the Next, Previous and Submit buttons is similar to what we saw before. The "Submit" button was set to be shown when the "$scope.currentPage" has a value of 7 which means this is the final step of the form. Also a couple of interesting directives have been added to the "Next" and "Previous" buttons which enable a lot of functionality with very little code. We see the "$scope.changePage()" method sent to be evaluated by the "ng-click" directive which, as the name suggests, evaluates it's parameter which in our case is the function when the user clicks the button. Also we added the "ng-class" directive which enables or disables a custom class to be added or removed dynamically by the framework if the expression it is given evaluates to TRUE. In our case, for the first button, we want to set the "disabled" class in the situation where we are on the first step of the form in order to disable the "Previous" button which is done through CSS. Exactly the same logic was applied for the "Next" button, only the expression to be evaluated checks if the form is on the last page. As we can see, a multi page form with a basic error validation system, confirmation and submission could be created with fairly few lines of actual code by splitting the logic between the controller and the view.
Directives
The reason
During the implementation stage of our project we found that some components are reused across pages and thought about how could we encapsulate these functionalities into some sort of entities which could easily be added wherever we wanted. Taking into account the power of dependency injection presented earlier, the answer for the right way of implementing such injectable components were the Angular's Directives.
A Basic Directive
An implementation of a side menu was needed on all the faculties pages which standed as a faster navigation aid between them.
In order to create a directive, the same method of creating a component by calling it's method with the same name on the module of the application was used in the case of directives, again with the firs parameter as a string which denotes the directive's name. A thing worth mentioning in the case of naming directives is the fact that Angular enforces developers to use camel case notation when declaring directive names as they will be transformed from that into a dashed notation when used inside HTML since the HTML elements and attributes should always be lower cased. What the framework basically does internally is split the title of the directive into as many words as it contains and separates them with a dash, so when we will want to use the above shown directive, we will use it with the following tag: "<side-buttons> content </side-buttons>". Moving over to how the implementation process took place we can see that the first property of the directive we mentioned was the "restrict" configuration parameter. (1) This was set to "E" which stands for "element" and is basically telling the framework that our directive will be included into the view as an HTML element. Next, we need to define a controller (2) for our directive which is basically the code that controlls the directive itself and inside we have set a property to the scope as "$scope.buttons" and assigned an array of objects which stand for the title of the button and the state to which the button should route to. This means, as in the previous examples, that we will have access to this value inside the directive's template (3) which is the next property defined. In our case when we want to display just a list of buttons, we can specify the HTML of the template inline, as opposed to setting a "templateURL" property and setting it's path to an external HTML file which would be used as the view of the directive. Taking a look inside our directive's template we see a nested native angular directive "ng-repeat" which basically acts like a classic "forEach" function and iterates over the given set of elements called "buttons" which, in the controller's definition, was set on the $scope variable with an array of objects which contained the information needed for rendering the information. Also, we have implemented view-sourced state changes through the "ui-sref" attribute which uses the "link" property of each object in the provided array. After Declaring the directive as above, all we need to do to actually use it is insert a "<side-buttons>" HTML tag and the whole rendered content will be displayed at the place where the element is put.
Use and results
As stated earlier, in order to use our directive, all we have to do is place the newly created tag inside our HTML and our framework will take care of all the connections that need to be made in order to render it properly. So basically, by adding a single line of HTML code (<side-buttons></side-buttons>) we get the following result anywhere in our application.
External Components
For a better overview of the contact page, especially when it comes to showing addresses, we decided to use a javascript implementation of Google Maps using "Google Maps JavaScript API v3". This way we could define how the map displays, configure it's controls and display multiple maps if needed which were advantages we appreciated over the classic embedded style of adding maps to websites. The first step was including a script tag in our html which requests the JS library used to display the map together with an API key so we will be able to obtain demographic analysis or analytics in the future if needed as all the requests to the Google Maps service which are routed through an API key are recorded and statistics are built upon. The implementation looks like this:
The implementation is not very complicated as the API is very rich and offers easy configurability. We only needed to declare the geographic coordinates, the zoom level and the center of the map and instantiate the map with those options using the "google.maps.Map" constructor and specify an element in which to put the map in which is the element with the id of "map-canvas". The quickly generated result looks like this.
Besides just showing the map we also want to add a marker in the middle to pinpoint the exact location of the institution unit, give it a title to be shown when the user hovers over it and specify it's position which is the same as the map's center. Also, all the Google Maps functionalities are enabled such and Satellite View and Street View directly onto our application which can provide a great user experience during the process of finding a location.
PRESENTATION
This chapter will consist of a basic presentation of the application as a whole, it’s structure and it’s usability and will be focusing on the core components. The main features and functionalities will be highlighted as well as other important relevant information.
Homepage
This is the landing page of the application and acts as the main presenter of what the website’s purpose and targeted audience is. As stated in the introduction, the target of the project was the creation of an informational site for admission candidates for UTCN as well as provide guidance and functionality towards the admission exam registrations. The front page highlights all the main interest points for a user of our targeted audience towards reaching his goals in obtaining or submitting information. The carousel slider serves as the main attention catcher which consists of a suggestive background image, a short message joined together with a brief description and a button linking to the related page in the application. The three main tiles serve a similar purpose, the only difference being that they remain static and, the two elements together combined were thought to contain the most relevant information which a user would want to find when using the website. The design and architecture of these elements was planned to offer high flexibility in terms of changing the content inside them and the end-points of the website they route to depending on what the owner of the website wants to at any given time and with ease.
Besides these attention drawing elements we have also added a navbar which persists across every page of the website for ease of navigation between interest points.
The lower part of the home page mostly consists of an informational area which shows the latest news and events but also contains a simple 2-input form for asking a question related to some information which may be missing from the site or offers the user the ability to view the FAQ section by clicking the highlighted link.
Faculties pages
The faculties pages have the sole purpose of informing the user about the admission conditions and other useful information regarding any given faculty. The first step of reaching a specific faculty page is by navigating to the general faculties page which looks like this:
This page is composed of a 3×3 matrix of tile buttons which contain a suggestive image and icon for each of the faculties which is linked to the faculty’s specific page and a side menu on the left side which consists of related links to where the user currently is at this point in the application.
Each individual page contains all the relevant information related to the admission process of the faculty and allows the downloading of relevant files such as admission calendars, sample exams, etc.[17]
Also, for easier navigation and comparison between these similar pages, a side menu was added on the left part of the screen which reflects which faculty the user is currently viewing and allow navigation between all the available pages.
Contact page
This page contains the basic contact information of the recruitment center as well as a javascript implementation of a Google Map centred at the according address and which also allows the use of Google’s Street View or Sattelite View. These tools can be helpful towards offering the user the most information possible related to what he is looking for.
Besides the static information, a contact form was also implemented to offer the user the ability to send a message to the recruitment center as an alternative to manually sending an email.
Registration forms
The registration forms for both exam simulation and the actual exam have the exact same structure as the same data points are needed to be collected in order to obtain a valid submission to one of the two. The form is a multi-step one which basically means that it requests and takes in the information in multiple steps and enforces validation after each step. This avoids confusion when filling up sizeable forms like ours which holds over required 40 data points and also provides an extra confirmation step at the end of the whole process.
Basically the form does not let the user proceed to the next step until all requirements are met and all the input fields pass the validation process. As soon as the user reaches the last step in completing the form he will be prompted with a confirmation button while he is able to see but not to edit all the previously entered data and confirm it if it is correct. If the user decides that the entered data needs to be changed, he can return to any of the 7 steps at anytime
.
USER’S MANUAL
The web application and integration system was built for a UNIX based operating system (Linux distributions, OS X) but was particulary created on OS X.
Getting the application's source files
In order to get the application's source files one would have to either copy them from the provided CD or from the git repository, using the following command in the command line:
>> git clone https://github.com/AndreiBru/orca-licenta
Installing npm and bower
The next step in order to get the automated integration system up and running one would need to install NPM and Bower, the two package managers used in this project.
For npm one can either download and install it manually from the NodeJS website [https://nodejs.org/] or if one is familiar with Mac's homebrew package manager, it could be installed by typing the following command in the terminal.
>> brew install node
Bower will be installed using npm using the following command:
>> npm install bower -g
By -g is meant that bower will be installed globally, in other words, a symlink will be created between the application and the global namespace so in this way we can use Bower directly from the terminal regardless of the current path.
To install the Bower and NPM dependencies inside the project, one needs to change the current directory to the application's directory using the „cd” command.
>> cd path/to/project
Npm and bower installations will be made directly from the terminal using the following commands:
>> npm install && bower install
Building the APP
The package.json and bower.json files which are already filled up will provide the necessary information for the package managers to know what dependencies to fetch. Now, having the system up and running, the next step is to create the application itself out of the source code this is made by the gulp command
>> gulp
By simply entering the „ gulp” command, this will run the build process with the default environment, which in our application is the development environment.
In order to obtain a production build of the project which includes the minification and concatenation processes of the code, you must add the following flag when running the command.
>> gulp –env=prod
Building the application in development mode renders the build files mirrored to the source files for easier browser debugging.
>> gulp –env=dev
After completing the steps above, the system creates a web server at "localhost:3000" it should be noted that this the port of this address can be configured from the gulpfile if needed. After the server is up and running, the process of deployment starts and runs continuously.
In order to run the application one will have to connect to localhost:3000 on a web browser in order to run the application.
If one would want to test the application on a mobile device, or any other machine that is not the web server he would need to access the server machine's IP followed by :3000 in order to see the application.
Building the app using its CRUD operations
For running the application including its CRUD (Create Read Update Delete) functionalities one would need to install XAMPP. This can be done from XAMPP's website at download section (https://www.apachefriends.org/download.html).
If the testing is done on OS X, one will need to stop the machine's native apache daemon using the following command:
>> sudo apachectl stop
then start XAMPP's apache and MySQL services.
Our gulpfile handles the publishing of the build to XAMPP’s apache on an OS X machine but the paths may differ on different operating systems. If that is the case, an edit must be done inside the gulpfile inside the ‚apache’ task which runs a series of BASH commands. What basically needs to be changed is the destination folder set inside that task for each of the files that get copied.
CONCLUSION AND FUTURE IMPROVEMENTS
Conclusion
During the development process of this project we managed to realise an adaptive development environment with GulpJS for a modern responsive web application for admission registration at the Technical University of Cluj-Napoca using modern frameworks and state of the art technologies. The building process of this project was a great learning tool since we needed to tackle lots of succinct or more complex problems, decide over suitable compromises in unlucky times when this was needed to and, one of the hardest things to achieve which was the mutual contribution and management of building a project in a team of two, each having different components and tasks assigned. Also, from a technical perspective, we learned how to join multiple technologies along the way and use them for what each does best in terms of a qualitative and consistent delivering process.
Further improvements
Admin panel
Considering that at this moment the web application can only be accessed as a user, we think that an admin panel is the next step in improving it. By creating that the application will provide a lot of features for the recruiting office.
• ability to export data from database to different formats (excel, pdf etc) by only clicking a button
• visual statistics in order to create different reports like students from a specific country , or number of students registered last week, the ammount of questions submitted in a day etc.
• possibility to create different charts or graphs based on the statistics mentioned earlier
• altering different tables from database in case let's say a student withdraws, or removing or creating new tables based on the current year
• real-time notifications on the admin page. By that we mean that a small pop-up should appear every time a student registers, or more useful, every time someone submits a question.
Virtual tours
We currently have the assets of virtual tours of the University so the implementation of virtual tours on each of the faculties pages would be a great interactive addition to the end product since they are a great attention catcher and also can provide a better visual experience than a classic images gallery can. This would be done through an embedding implementation over an external service which provides this functionality.
Better assets management
Currently, all of our physical assets such as images are at the largest resolution available to fit even the largest of the screens. As the project stands on a responsive design pattern we may add custom resized images for each device type in order to improve load time and data usage, the latter being a relatively important reason since most mobile devices when not connected to a WI-FI network use the 3G/4G technologies for accessing the web which is usually not unlimited for most mobile device users. Also, considering the lower processing power of smartphones when compared to desktops or notebooks, the reduction of the load time could be a great user experience enhancer.
7.2.4 Protractor automated tests
For this project's end-to-end testing we used the Selenium IDE which is practically a user action replicator. By using a code based automatic end-to-end testing system like Protractor which has a syntax similar to Jasmine so basically we could actually write tests in code rather than actually recording a manual user action and using an external software to reproduce it. By using a framework like Protractor, we can also add the process of running and maintaining the tests into our already build integration system's workflow.
7.2.5 Interactive calendar
The addition of an interactive calendar on the faculties pages instead of offering the user a file to download in which to view the addmision calendar in would be a great helper for the users since it can be placed in a easy to view place and save time for the users by avoid the manual searching and understanding of the calendar.
7.2.6 Interactive maps
Again a feature thought about for the faculties pages, an interactive map much like the one on the Contact page could be added to each of the faculties and display all the interest points for each of the faculties such as amphitheatre or laboratory locations through the city where a certain faculty may have classes at, material aids such as Copy stores based on each department's needs or any other relevant place on the map where a student may be interested to reach, especially before admission.
Bibliogrphy
[1] http://www.computerhope.com/jargon/h/http.htm
[2] http://searchenterprisewan.techtarget.com/definition/File-Transfer-Protocol
[3] http://www.w3schools.com/website/web_tcpip.asp
[4] http://www.simplehtmlguide.com/whatishtml.php
[5] https://en.wikipedia.org/wiki/Cascading_Style_Sheets
[6] https://developer.mozilla.org/en-US/docs/Web/JavaScript
[7] https://en.wikipedia.org/wiki/JavaScript
[8] Raul DOLHA, "Public web application running under continuous integration system – Development environment and automated
testing"
[9] http://www.inmotionhosting.com/support/edu/joomla-3/using-bootstrap/what-is-bootstrap
[10] https://jquery.com/
[11] https://angularjs.org/
[12] http://fm.cnbc.com/applications/cnbc.com/resources/files/2014/01/22/comscore.jpg
[13] http://changemarketing.ca/wp-content/uploads/2015/04/desktop-vs-mobile-most-popular-devices-2015-550×719.png
[14] http://boatboat001.com/upload/img/responsive_design.png
[15] http://www.angularmiami.co/img/data-binding.png
[16] http://www.codeproject.com/KB/scripting/709340/Application_-directive-and-VM.png
[17] http://www.utcluj.ro/admitere/licenta/
[18]http://searchenginewatch.com/sew/opinion/2353616/mobile-now-exceeds-pc-the-biggest-shift-since-the-internet-began
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Realizarea Unui Magazin Online (ID: 103061)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.