MASARYK UNIVERSITY FACULTY OF INFORMATICS

Software transition from Flash to HTML5

MASTER’S THESIS

Marián Rusnák

Brno, 2016

Declaration

I hereby declare that this thesis is my original authorial work, which I have completed independently. All sources, references and literature used or ex- cerpted during elaboration of this work are properly cited and listed in complete reference with links to the original sources.

Advisor: doc. RNDr. Tomáš Pitner, PhD.

v

Acknowledgement

I would like to thank Peter Krafčík and Martin Klimo from Interaktívna škola s.r.o. for the opportunity to work for them and for making this thesis possible. Next, I would like to thank my advisor, doc. Tomáš Pitner for his patience, for his valuable advices and for his positive attitude through my studies at the faculty. Special thanks go to Dušan Piroh, my colleague and my brother-in- law, for mentoring me throughout my entire life and for initiating my inter- est in development and computer science. My gratitude also goes to my co-workers from AOL in London for their inspiration and support. Specifically, I would like to thank to Samuel Adu for all his effort in my English language revision. Big thank goes to my parents and my family for pushing me in writ- ing of this thesis as well as the entire studies. After all, I would like to thank all the influencers in the software de- velopment industry, all the smart people around me and my teachers for their contribution to my knowledge and skills required to finish this thesis.

vii

Abstract

The aim of this thesis is to describe the process of manual transition of soft- ware from technology to HTML5. Alf software, interactive tests creator and player, a non-trivial application made in Flash, is the main area of focus. The output of this thesis is a new HTML5 version developed from scratch, as a replacement for the former Flash one. The thesis describes its development from requirements specification to implementation and vali- dation. It also includes a comparison of Flash and standard web development workflows. Apart from HTML and other web technologies, which are mentioned in the thesis, it also outlines other development options to support the growing mobile platforms, including specifics for Flash.

ix

Keywords

Alf software, Adobe Flash, HTML5, web, mobile, Single-Page Application, animations, interactive, ECMAScript 2015

xi

Table of Contents

1 Introduction ...... 1 2 Alf Software ...... 3 2.1 Overview ...... 3 2.2 Technologies...... 6 2.2.1 Adobe Flash ...... 6 2.2.2 Desktop Application ...... 8 2.2.3 Mobile Support Limitations ...... 8 3 Options for Supporting Mobile Devices ...... 11 3.1 Native Applications ...... 11 3.2 Web Applications ...... 12 3.2.1 Mobile UI Frameworks ...... 15 3.2.2 ...... 16 3.2.3 Web Designer ...... 16 3.3 Hybrid Applications ...... 16 3.3.1 PhoneGap ...... 17 3.4 Native Cross-platform Approach ...... 17 3.4.1 Xamarin ...... 18 3.4.2 Appcelerator Titanium ...... 18 3.4.3 NativeScript ...... 18 3.5 Flash-based Approaches ...... 19 3.5.1 Adobe AIR...... 19 3.5.2 Swiffy ...... 19 3.5.3 Mozilla ...... 20 3.5.4 HTML5 Canvas Document ...... 20 3.6 Summary and Conclusion ...... 20 4 Web Technologies ...... 23 4.1 HTML5 ...... 23 4.1.1 Canvas ...... 24 4.1.2 Audio and Video ...... 24

xiii TABLE OF CONTENTS

4.1.3 Other Features ...... 25 4.2 CSS3 ...... 25 4.2.1 Transformations ...... 25 4.2.2 Transitions ...... 26 4.2.3 Animations ...... 26 4.2.4 Other Features ...... 27 4.3 SVG ...... 27 4.4 JavaScript...... 28 4.4.1 Modules...... 29 4.4.2 ECMAScript 2015 ...... 29 4.4.3 Single-Page Application Frameworks ...... 33 4.4.4 Testing ...... 34 4.5 Build ...... 35 5 New Alf HTML5 Application ...... 37 5.1 Requirements ...... 37 5.1.1 Functional ...... 37 5.1.2 Non-functional ...... 38 5.1.3 Browser Support ...... 38 5.2 Analysis and Design ...... 40 5.2.1 Client-side Frameworks Analysis ...... 41 5.2.2 Prototyping ...... 41 5.2.3 Architecture ...... 43 5.2.4 Single-Page Application ...... 46 5.3 Implementation ...... 48 5.3.1 Back-end ...... 48 5.3.2 Front-end ...... 49 5.4 Comparison to Flash Development ...... 59 5.4.1 User Interface ...... 59 5.4.2 Animations ...... 59 5.4.3 Drag & Drop ...... 60 5.4.4 Audio ...... 60 5.4.5 Optimization ...... 60

xiv TABLE OF CONTENTS

5.4.6 Compatibility and debugging ...... 60 6 Conclusion ...... 63 6.1 Areas for Further Development ...... 63 References ...... 65 Appendix A: Screenshots of all the Alf Tasks...... 73 Appendix B: Source Code ...... 91 Appendix C: Prototypes and Experiments ...... 93

xv

1 Introduction

It was the year 2007 when Apple introduced its first iPhone and brought a revolution into the way how we interact with computers. That year, a little mobile computer, known as a smartphone, was born. Together with the rise of tablets, mobile devices became a part of our everyday lives. Today, we can use them to perform almost any task we would have traditionally tack- led with a desktop or a laptop device. For some people, smartphones are the first computers they use in their life. It was a decade before the first smartphone when the Adobe Flash technology was introduced. Flash has played a leading role in bringing new capabilities to the web. From audio and animation, to interactivity and video, Flash has helped push the web forward. It was a platform which ena- bled developers to push web applications from static web pages to a completely new level of interactivity. This is what enabled Alf software to be created – using Adobe Flash technology. A highly interactive test creation tool gave teachers ability to attract students and opened new ways how to transfer knowledge. However, nothing lasts forever and that holds for Flash as well. What started with his criticism of Flash was followed by other vendors and that has slowly started to be the end for Flash in this post-PC era. Due to the lack of support for Flash on mobile devices, the industry started a shift away from Flash. Web technologies are meant to be the re- placement. The HTML5 standard has long been around, but has not been a viable replacement for Flash mostly due to the lack of support of certain features in web browsers. I believe this is no longer the case and this thesis aims to prove it. The main focus is on the manual transition of Alf software from Flash technology to HTML5. It provides an overview on how a new HTML application is created from scratch, based on the existing predecessor in Flash. Focus is on several key Flash features such as animations, drag & drop, and user interface design. This thesis is divided into 6 chapters. This short introduction is fol- lowed by the overview of Alf software, its functionality and technologies. The aim of the third chapter is to provide an overview of various possible options for supporting the growing market of mobile devices, not limited to standard web technologies. It is concluded with a short comparison of the described technologies and methods. The fourth chapter is devoted solely to current standard web technologies and modern approaches to web devel- opment. The fifth, and the most important chapter, describes the whole pro- cess of building a new HTML5 application as a replacement for the previous Flash version. It describes the development from requirements specification

1 1. INTRODUCTION to implementation and validation. The comparison between the develop- ment of the Flash and HTML5 versions is presented at the end. The thesis is then concluded in the sixth chapter, containing areas for future development as well. Alf software is a commercial product, owned by a privately held Slo- vak company Interaktívna škola s.r.o. Therefore, the requirement for this thesis to be created was initiated by the company and it has direct industrial usage.

2 2 Alf Software

The purpose of this chapter is to provide an overview of the Alf software and some of its related systems. It was partly done in Chapter 2 in my Bach- elor thesis [1], so this chapter is based on it while extending some information, adding some more up to date information and providing it in English instead of Slovak.

2.1 Overview Alf software [2] is a tool aimed to support educational process at schools. It helps teachers to attract their students with interactive tests. Teachers can create tests themselves and then use them to assess students’ knowledge, or use them during lessons on a virtual board. The software aims to keep the students engaged due to its highly interactive user interface. Alf tests can consist of multiple types of tasks (also referred to as Alf tasks) some of which are more of an interactive game than a task in the test. Every test can contain unlimited number of tasks of any type and it is the teachers’ imagination or creativity that is the limit for creating the tests. They can be enhanced with media (pictures or sounds) to make them more attractive. These media files can be displayed or played directly within the test. It is a step forward from conventional paper testing with static content only. Currently, Alf software offers 16 different types of tasks. The list be- low contains their short descriptions, whereas Appendix A: contains the screenshots of all the available Alf tasks, developed in the new HTML5 ap- plication. Supported tasks are the following:

 Single Choice (text) – Selection of one correct answer from up to 6 options. Question can be enhanced with a picture, sound or any other file as an attachment. Answers can simply be plain text.

 Single Choice (pictures) – Similar to the previous one, with the exception that pictures and sounds can be added to answers as well.

 Multi Choice (text) – This type is the extension of the Single Choice (text) with multiple correct answers possible.

 Multi Choice (pictures) – This type is the extension of the Single Choice (pictures) with multiple correct answers possible.

3 2. ALF SOFTWARE

 Memory Game – It is a classic game in which the goal is to find matching pairs among hidden cards. In this Alf task, you can de- fine up to 8 pairs of cards containing text, picture or even a sound.

 Category Sort – In this task, you organize texts into groups. There can be up to 4 groups.

 Matching (text) – This task is about matching related pairs of statements to each other.

 Matching (pictures) – Similar to the previous one, but the state- ments can be accompanied with pictures and sounds.

 Order (vertically) – This task is about putting texts in the correct order.

 Order (horizontally) – In this task the goal is to put letters, parts of a word, or the words in a sentence in the correct order.

 Picture Labeling – When creating the test, authors define their own labels on any position in the picture. When solving the test the goal is to assign those labels to the correct positions.

 Flashcards – This type is about deciding whether two cards repre- sent a match or not (are equal or not). There can be multiple pairs displayed in a sequence. This task has a special feature that it can be set up as a game between 2 players.

 Puzzle – In this task, the goal is to solve a puzzle. A picture is di- vided into pieces and shuffled, and the task is to compose the original picture.

 Guess the Word (hangman) – The goal is to guess a word by try- ing whether the word contains individual letters until you run out of turns.

 Crossword – In this task, each row contains a question, which needs to be answered in the corresponding cells. At the end, one of the columns should contain some final result.

 Gap Filling – Multiple words are available to be used to fill the gaps in a given text.

The last three types are new in the latest version 3.0 released in 2014 and they are not described in my Bachelor thesis.

4 2. ALF SOFTWARE

Any test would be useless if we could not gather any results from it. Therefore, when a user is solving an Alf test, the software collects points for each correct answer. The amount of points awarded for each question can be adjusted when creating the test. Then, at the end of the test, the user can see the final result. Additionally, each task can have a time limit. If this time limit is exceeded after a task has been started, the task will be automatically terminated. Alf software is now distributed with the new light theme1, not present in the version described in my Bachelor thesis. It was created to be more visible and readable on data projectors in classrooms. The theme design is also less formal than the old one and therefore more suitable for young stu- dents. The new theme is shown in Figure 1.

Figure 1: Home screen in Alf software with the new light theme

Two web portals were developed in order to support the usage of Alf software and its adoption among teachers: Test Database2 and Online Test- ing3. The first one is a universal source of educational materials for teachers, not limited only to Alf tests. It contains materials from various authors and

1 You can still choose the old dark theme in the settings. 2 http://www.interactivetests.net/dtb/index.php?lang=en 3 Video with an overview of the features in Slovak language can be found on the address: https://www.youtube.com/watch?v=eOHF7UASKKs

5 2. ALF SOFTWARE registered users can upload and share their own pieces. Teachers can then search among them and reuse useful tests or other materials. The second web portal – Online Testing – is an e-learning system where teachers are able to assign tests to their students, let them take the tests online and see their results. It is interconnected with the Test Database. Online Testing was a result of my Bachelor thesis [1]. The major market of the Alf software is Slovakia, where it was founded, followed by Czech Republic. However, the software is aimed to be international and it is localized into 11 languages: Czech, English, French, German, Hungarian, Polish, Russian, Serbian, Slovak, Slovenian and Span- ish. It is mainly used in primary schools, but it can be used also in secondary schools, kindergartens or possibly in any educational institution.

2.2 Technologies Alf software was initially developed in 2010 as a desktop application for , but over the years it has become available online in web browser as well. This extension was achieved with a minimal effort, because the software is based on the Adobe Flash platform4, which is supported in web browsers on PCs. The online version enables users to preview tests from the Test Database or students to pass the tests in Online Testing di- rectly in the browser without installing the software into their . Although, the code base is shared for both desktop and online ver- sions, the test creation part is excluded from the online version and it can be treated as a test player only.

2.2.1 Adobe Flash Adobe Flash is a software platform for creating animations, games and Rich Internet Applications (RIA)5. It was invented in 1995 in a small company FutureWave, later acquired by , which was again acquired by Adobe Systems in 2005. Flash gained its popularity because of very good support for bitmap and vector graphics, and multimedia. Flash-based appli- cations run inside the Adobe Flash Player6, the runtime environment in- stalled on a user’s device or provided via a web browser plugin. This Flash Player is specific for every OS and it gives us a compatible interface for applications, hiding the differences between the operating systems. This concept is similar to JVM (Java Virtual Machine) and it helps in developing applications for multiple platforms.

4 https://www.adobe.com/products/flash.html 5 A Rich Internet Application (RIA) is a Web application that has many of the characteristics of desktop application software, but it is delivered via a web browser. 6 https://get.adobe.com/flashplayer/

6 2. ALF SOFTWARE

Figure 2: logo7

Adobe Flash Professional (formerly Macromedia Flash) is an official tool for creating Flash-based applications. Its user interface is similar to graphics software. However, Alf software was not created using the official Flash tool, but in a 3rd party solution called SWiSH Max8. It offered better licensing strategy9 [3; 4] and the user interface was easier-to-use10 for creat- ing simple applications.

Figure 3: SWiSH Max user interface with Alf software’s project opened

7 http://blogs.adobe.com/flashplayer/files/2013/11/flash_player_11_icon_rgb.png 8 http://www.swishzone.com/index.php?area=products&product=max 9 Single user license for SWiSH Max costs $149.95, while for Adobe Flash Professional you have to pay $19.99 per month. With this monthly price you overpay SWiSH Max license in less than one year of usage. Back in 2010 the license for Adobe Flash Professional CS4 did not have a monthly, but a permanent cost $699. 10 The opinion is based on my experience and the experience of my colleagues with both tools.

7 2. ALF SOFTWARE

ActionScript Flash supports scripting via the ActionScript language [5], derived from ECMAScript [6], to create interactions in the applications. SWiSH Max offers a small variation of ActionScript [7] and it does not support the latest, back- ward incompatible version ActionScript 3.0. Therefore, Alf software was developed using version 2.0.

2.2.2 Desktop Application Flash is not intended to be used to create full-featured desktop applications, because it does not support basic OS operations like working with file sys- tem. However, Alf software was built with a special compiler mProjector11, which enhances Flash applications with extra capabilities common for desktop applications. It converts the Flash format (SWF) into the executable file (EXE). Usage of mProjector brought a revolution into the Alf software. It was used for the first time in version 2.0, which was the first one to enable mul- timedia in the tests.

2.2.3 Mobile Support Limitations Unlike mProjector was used to build the desktop version, the same method cannot be used for packaging mobile applications. Unfortunately, mProjector supports only Windows and Mac OS. Flash applications can run in web browsers via the Flash Player plugin, but this is true only for brows- ers on PCs. Adobe claims not to support Flash on mobile devices: “We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) fol- lowing the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.“ [8]. This suggests a dark future for the Flash platform on mobile devices and in general too. Declined mobile support is a consequence of Flash’s criticism from several notable individuals. Historically, one of the biggest critics was Apple’s former CEO Steve Jobs. He wrote his in 2010 [9], mentioning the following drawbacks for Apple iOS12:

 Flash is a proprietary technology.

 It does not have any added value for iOS.

 It lacks reliability, security and performance.

11 http://www.screentime.com/software/flash-projector 12 Operating system used on mobile phones from Apple.

8 2. ALF SOFTWARE

 It reduces the battery life.

 It does not support touch devices well.

 It can possibly harm innovations on the iOS platform.

Later he concludes: “Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open – all areas where Flash falls short. “ Lack of Flash support for mobile devices is problematic for the current state of Alf software. It cannot be used on mobile devices just as it is – either in web browser, or packaged as mobile application – and changes have to be made. The options we have to make a transition to mobile devices are de- scribed in the Chapter 3 – Options for Supporting Mobile Devices. It should be noted that there are ways to make Flash Player work on mobile devices. For example, Samsung tablets which are distributed to schools in Slovakia via the Project DiGiŠkola13 come with the support for Flash [10] and it is possible to run Alf software online in web browser. How- ever, this solution is not reliable enough and it does not give us very broad support.

13 http://www.digiskola.sk/

9

3 Options for Supporting Mobile Devices

The mobile world has developed within the past years and has become in- credibly large in terms of users, devices and platforms. We can see even faster progress and greater rate of innovation in mobile devices than we see in conventional PCs. This chapter covers several methods of how to build applications for mobile devices, enabling us to target our application to an increasing num- ber of mobile users. There exist several mobile platforms, but in this chapter, if not specified, we focus on the three most popular ones at the time of writ- ing – Android, iOS and Windows Phone [11].

3.1 Native Applications The first option when developing applications for mobile devices is the most straightforward – native applications [12; 13; 14]. Developed in a language specific for the target platform, native application can use the most of the ecosystem and features of the device, and gives the user the most native ex- perience. These applications can be installed on the device from the official centralized portals containing all the supported applications for the given mobile operating system. These portals are known as “app stores” and are unique for each operating system – Google Play14 for Android, Apple App Store15 for iOS and Windows Phone Store16 for Windows Phone. Developers have to submit their applications into these app stores and every application has to be approved by the owner of the platform. The advantage of native applications, comparing to other develop- ment methods, is usually performance, because they do not need any additional runtime environment, but the operating system itself. This is usually an issue for tasks which heavily consumes computing resources such as: image processing, 3D rendering or video editing. Native applica- tions are also beneficial for the user. They are available on one place in the where the user can easily search among them, see the reviews from other users, check the compatibility with his/her device and install them with usually just one click. Moreover, the app store is maintained by the authority responsible for the security of the users and tries to check all the applications for any vulnerability.

14 https://play.google.com/store 15 https://itunes.apple.com/us/genre/ios/id36?mt=8 16 http://www.windowsphone.com/store

11 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

On the other hand, native applications have several drawbacks for the application developer, especially if he/she wants to support many devices. Every mobile platform requires its own development, its own programming language and development tools, its own user interface design and its own submission into the app store. Primary programming languages for mobile platforms are the following:

 Android – Java

 iOS – Objective-C

 Windows Phone – C#

Therefore, when a developer aims to support multiple platforms with native applications, he/she needs to create a set of completely separate ap- plications. The consequences are that the development is either more costly, more time consuming, or both [15]. Additionally, it requires developers who are experts for all the different mobile platforms, which again raises the price of the development. For some companies this can be unaffordable, so they cannot develop several native applications and they prefer other op- tions which are described in the following sections.

3.2 Web Applications When referring to web applications we usually mean the applications which are displayed by a web browser. Today’s web is a large ecosystem for rich applications full of multimedia, animations, interactions, user-created con- tent and recommendations. The old days of static HTML pages are gone. Web browsers improved in the past 3 decades from applications for parsing and displaying HTML to the multi-purpose applications supporting vast array of technologies. Web technologies evolved so that they can now be used to build very complex applications which can be running for a long time without browser refresh. Nowadays, we can see a lot of such applica- tions, Facebook17 or Gmail18 being good examples. Mobile devices, despite their size comparing to traditional PCs, have enough computing power and are shipped with modern browsers compatible with the latest web technolo- gies. This makes them suitable for running complex web applications via a web browser. It is relatively easy to design a user interface for an HTML applica- tion. We have a good tooling support for HTML and a lot of people with experience in . I consider this among the main advantages of HTML applications. Also, Microsoft saw this fact and introduced HTML

17 https://www.facebook.com 18 https://mail.google.com

12 3. OPTIONS FOR SUPPORTING MOBILE DEVICES apps to be one of the ways to develop Windows 8 Modern UI applications19. Later, Microsoft went further announcing: “Windows 10 will make it easy for you to create a Windows app that packages your website for publishing to the Store. Once installed, your website can update and call Universal APIs from JavaScript, creating a more engaging user experience.“ [16] Since Windows 10, HTML apps with JavaScript are part of the Universal Windows Platform (UWP) [17]. Along with the advantages, there are also the following problems of web applications:

 Limited support for offline mode

 Absent native mobile UX (user experience)

 Missing some mobile APIs

Although, HTML includes technologies for building offline-enabled apps20, it is less straightforward and not so common to see such apps. Also, you have to contend with the quality of the internet connection, which, in fact, holds for native apps as well. In 2015, we could have seen an increased popularity of so called Progressive Web Apps [18; 19]. They use couple of tech- nologies which replace former technologies for offline applications and pro- vide better experience for developers. Therefore, we may see growing num- ber of offline web applications in the short future. Probably the biggest drawback of web applications running on mo- bile phones is that they hardly overcome native applications in terms of UX, which is specific for the particular mobile OS. Every mobile platform has its own style guides and a web application does not have any access to the na- tive UI (user interface) controls. Users are used to some standard design on their OS and web apps can usually be recognized as different. Web technologies improve and include some features common for native apps such as push notifications. However, some important APIs for building mobile apps are still absent, or their support is not sufficient. Ex- amples include Battery Status API21, Screen Orientation API22 or Media Capture and Streams23 for mobile Camera usage. Unlike native applications, web applications are those in which the developer has access only to the limited amount of features of the device.

19 They were previously called Metro-style applications. 20 https://html.spec.whatwg.org/multipage/browsers.html#offline 21 http://www.w3.org/TR/battery-status/ 22 http://www.w3.org/TR/screen-orientation/ 23 http://www.w3.org/TR/mediacapture-streams/

13 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

The most significant advantage of web applications is that they can achieve broader support than native applications. Just one application is needed to run on mobile devices as well as laptops, PCs, TVs and many more devices with a web browser. Although, it may seem like the same code is used to target all the us- ers on all the devices, it is not always true. With web applications you also have to face some specific issues like:

 Incompatibilities among browsers

 Bugs in browsers

 Different screen sizes and resolutions

 Different input methods (touch, keyboard, mouse, …)

You face the last issue if you want to develop one web application to run on all the web-enabled devices. However, there are frameworks and li- braries which come to hand in such situations. Regarding the incompatibilities and bugs in browsers, the browsers evolved over time and the differences are on a much lower level than they used to be. Web technologies are more standardized and browsers vendors try hard to implement new features and align with each other and with the organization who defines the standards. And if you still find some incom- patibility, you can use techniques to detect features in browsers and react appropriately. When supporting all types of web-enabled devices with different screen sizes, you usually need to display slightly different content on small mobile phones than on 25 inch PC screen or even 50 inch TV. You have two options how to achieve it:

1. Use CSS3 media queries24

2. Develop several versions of your web application for different screen sizes

CSS3 media query is a feature of CSS, introduced in the 3rd version, which you can use to define different styles depending on a type of media (computer screen, TV, printer, speech synthesizer, etc.), screen size and color related features. In mobile browsers another technology can be helpful – meta viewport tag25. It gives browser the instructions on how to control the

24 https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries 25 http://www.quirksmode.org/mobile/viewports2.html

14 3. OPTIONS FOR SUPPORTING MOBILE DEVICES page's dimensions and scaling. It was originally an Apple’s extension in Sa- fari on iOS, but it was later incorporated by other browser vendors. With the second option from the list, several versions of a web appli- cation are developed and a server then decides which one to send to a client. Although, this approach removes the advantage of web development, it is used by some companies to serve a different version of their app for mobile devices than to PCs. The mobile version is commonly available on an ad- dress prefixed with an m (i.e. http://m.domain.com).

3.2.1 Mobile UI Frameworks One of the disadvantages of web applications mentioned above is the lack of the native mobile UX and controls. However, there are several UI frame- works (or libraries) that try to address this issue and help with various aspects of mobile web application development. Besides other features, they can help an HTML application to gain a native look and feel by providing some UI widgets.

Sencha Touch A relatively old and mature framework – in terms of the young mobile world – is Sencha Touch [20]. It was formed in 2010 after popular JavaScript library projects Ext JS26, jQTouch27 and Raphaël28 were combined. Sencha Touch includes a set of UI components designed for the mobile web and op- timized for touch screen devices. There is much more that the framework can offer like styling for specific OS, DOM manipulation, or application build tools [21].

Kendo UI Another popular framework is Kendo UI [22]. It is developed by Telerik29, which is famous for .NET UI widgets. Kendo UI offers HTML widgets with native design for each supported mobile platform including Android, iOS and Windows Phone. Its advantage is that it is based on jQuery30, a popular JavaScript library, which is familiar for many developers [23]. jQuery Mobile As the name suggests, jQuery Mobile [24] is a framework also built on the top of jQuery, and even developed under the jQuery Foundation31. It is also

26 http://www.sencha.com/products/extjs/ 27 https://github.com/senchalabs/jQTouch 28 http://raphaeljs.com/ 29 http://www.telerik.com/ 30 http://jquery.com/ 31 https://jquery.org/

15 3. OPTIONS FOR SUPPORTING MOBILE DEVICES one of the oldest in the category. Although, it is a JavaScript library, devel- opment in jQuery Mobile is mainly done in HTML and CSS. Apart from Sencha Touch and Kendo UI, jQuery Mobile components do not tend to have native design [25], but they are optimized for touch screen devices.

3.2.2 Adobe Edge Adobe realized the potential of web technologies and proclaimed its com- mitment to improve the web ecosystem [8]. They have since then worked on several HTML features, have been involved in the HTML standardization process in cooperation with W3C ( Consortium), or actively contributed to the browser engines to push the web technologies forward [26; 27; 28; 29]. Additionally, Adobe released new tools for developing HTML web applications [30]. Whereas there exist tons of such tools on the market, the central part of Adobe Edge tools – Adobe Edge Animate [31] – comes with a Flash-like approach for building web apps. Its UI is similar to graphics software and uses a timeline, which helps in creating and visualizing anima- tions. These are the areas in which Adobe Flash excels and, due to the latest web technologies, Adobe was able to bring such features to HTML web de- velopment.

3.2.3 Google Web Designer Google follows the Adobe’s path and has developed its own software with similar approach to the Adobe Edge Animate. It is called Google Web Designer [32] and it has simpler user interface and offers less advanced features than the competitor from Adobe. It is mainly focused on producing interactive HTML advertising, but it can be used for developing small applications as well. Because of its simplicity, it is very intuitive and user- friendly. The software is currently still in beta version, which can last for a long time as with other Google’s products [33]. Apart from all, Web Designer is a free tool, which makes a significant competitive advantage against Adobe Edge Animate.

3.3 Hybrid Applications Hybrid apps try to combine the advantages of web and native apps [34]. They are primarily built using HTML5 and JavaScript, and a detailed knowledge of the target platform is not required. Hybrid applications fully take advantage of the popularity of web development, but additionally these apps have access to the APIs for platform-specific features. At runtime, the platform’s WebView—essentially a browser without user controls—inter- prets the source code to display web pages. All calls to hardware APIs are delegated to the native wrapper.

16 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

The main advantage of hybrid approach is the reusability of user in- terface across different platforms utilizing native platform features. Usually, one application code base can be used on several mobile platforms, pack- aged as a native app. These apps are then distributed thorough the official app stores.

3.3.1 PhoneGap Amongst the most popular toolkits in the field of hybrid app development is PhoneGap [35]. It is a mobile development framework which enables developers to build mobile apps using standard web technologies, supplying them with access to the native APIs, and packaging the completed application for the various mobile app stores. Currently, it supports 9 mobile platforms. PhoneGap is being developed by Adobe Systems, but it was origi- nally developed by Nitobi, which was acquired by Adobe in 2011. PhoneGap gained its popularity and strong name as it was the first tool to come with this approach to building of mobile apps.

Apache Cordova PhoneGap’s source code was donated to Apache Software Foundation and released as open-source under the name [36; 37]. This is now the engine that powers PhoneGap and it is free to use standalone. Adobe supplies its paid product with some additional tooling and product support.

Ionic Several frameworks make use of the Apache Cordova, Ionic [38] being one of them. It is a framework which combines the popular JavaScript frame- work Angular JS (it is described in the Section 4.4.3), Apache Cordova hybrid app packaging plus adding some mobile UI components and tools [39]. Although, it is a relatively new participant on the market it has gained significant popularity [40].

3.4 Native Cross-platform Approach Another approach for mobile application development is the approach which is called native cross-platform in this thesis. It provides the ability to create a single code base and package it for various platforms. This approach is similar to that of hybrid apps and some texts do not distinguish between hybrid apps and native cross-platform apps. But I consider it to be different, because native cross-platform apps do not need a web rendering container (WebView) to run. They use native UI elements directly, which means they can possibly run with fewer resources and provide better look and feel. The

17 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

APIs of the device are accessed through special intermediate APIs, just like in hybrid apps.

3.4.1 Xamarin Xamarin32 is a company behind the Mono – open source implementation of .NET. After the increased popularity of mobile applications, Xamarin released MonoTouch for iOS and Mono for Android and thus enabled devel- opers to produce applications for mobile platforms written in C# – language of .NET. Later, these implementations were changed to Xamarin.iOS and Xamarin.Android, being a part of one Xamarin Platform [41]. The platform supports development for iOS, Android and Windows Phone, while for each mobile OS it uses different approach due to the limi- tations of that OS [42]:

 iOS – C# is ahead-of-time (AOT) compiled into ARM assembly language, as iOS does not allow runtime code generation.

 Android – C# is compiled into IL, which is just-in-time (JIT) com- piled into native code.

 Windows Phone – C# is compiled to IL and executed by the built- in runtime. Therefore, it does not require Xamarin tools as the official .NET is present on Windows Phone.

3.4.2 Appcelerator Titanium Appcelerator33 uses different approach than Xamarin and its product – Tita- nium [43] – creates native apps from a JavaScript codebase, which is then interpreted at runtime. It makes use of the underlying JavaScript engine, either provided by the mobile platform, or packaged with the app. While the approach could seem similar to that of hybrid apps, Titanium does not use a WebView, but composes a native UI elements controlled by JavaScript. It offers a cross-platform API in JavaScript.

3.4.3 NativeScript NativeScript [44] is similar to Appcelerator Titanium in the sense than it makes use of JavaScript. The technology is very promising as it enables de- velopers to use both native and JavaScript libraries in the same code base. Due to reflection34, a bridge between the JavaScript Virtual Machine and the native code can translate calls to the correct native APIs. Additionally,

32 http://xamarin.com/ 33 http://www.appcelerator.com/ 34 Reflection is the ability of a computer program to examine and modify its own structure and behavior (specifically the values, meta-data, properties and functions) at runtime.

18 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

NativeScript applications use native UI elements, which can prevent the degradation of performance comparing to fully native apps.

3.5 Flash-based Approaches Previous approaches to building mobile applications required developing a new application either shared across several mobile platforms or several versions of the app for each platform. However, if there is already an appli- cation in Flash, such as Alf software, we have several options that will enable us to use the same code base for mobile devices. This is described in the following sections. These approaches do not aim to produce mobile apps with a native look and feel, but rather to give you an option to use your ex- isting Flash app or generally to use the advantages of Flash technology on mobile devices.

3.5.1 Adobe AIR The first option and the most advanced is the Adobe AIR (Adobe Integrated Runtime) [45]. It is used to produce native apps with a built-in Flash interpreter and it is able to create not only mobile apps, but also desktop applications. Desktop is where Adobe AIR started, later extended to support mobile operating systems. AIR gives the application access to the OS-specific features such as file system integration, system menus, windows, camera, microphone etc. AIR-based applications frequently use animations and 3D graphics supported with GPU hardware acceleration. AIR applications are developed in Adobe Flash Professional and scripting is provided by ActionScript 3 [5]. In spite of the fact that Flash is no longer supported on mobile via the Flash Player, Adobe AIR is still availa- ble. On some platforms it is installed as a standalone runtime whereas on others it has to be embedded within the app.

3.5.2 Swiffy Swiffy [46] is a Google’s tool to convert existing Flash applications into their HTML5 alternatives. It is available as an online tool and an Adobe Flash Pro- fessional extension. The online version is capable of converting Flash apps only up to a size of 1 MB. In fact, the tool is usable only for simple Flash apps and produces somewhat unoptimized result, which is not ready for production. Google’s aim with the tool is to help creative agencies to transit their existing online advertising to HTML. The tool is included just for the reference, but I do not consider it to be a reliable option for building appli- cations.

19 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

3.5.3 Mozilla Shumway Shumway [47] is an HTML5 technology experiment that aims to render the Flash SWF file format by translating it into HTML5 on the fly. It translates the Flash content into HTML5 and ActionScript into JavaScript. This open- source experiment is still under development, primarily by Mozilla, and it is available as a Firefox extension. If the project proves to be successful and a reliable replacement for the Adobe Flash Player, it can possibly be integrated into Firefox. Although, Shumway seems to be a promising experiment, it is still not ready for real use and is still missing a lot of Flash features.

3.5.4 HTML5 Canvas Document Another form of conversion is developed by Adobe and included directly in Flash Professional [48]. It converts Flash project files – FLA – into HTML5 with canvas element. However, the conversion is limited only to special cases and is not suitable for more advanced applications, which holds true especially for ActionScript conversion [49]. Consequently, it requires a lot of manual code conversion. On the other hand, HTML5 Canvas Document can be used to create animated web applications from scratch. Adobe announced Flash Profes- sional is to rename to CC [50], being a universal animation tool. HTML5 Canvas is just one of the available publishing options in Adobe Animate CC.

3.6 Summary and Conclusion This chapter outlined many possible approaches to building mobile applica- tions, including several options that enable existing Flash content to be reused for mobile. As there were many pros and cons mentioned for each technology, Table 1 summarizes all the approaches. The summary uses the following criteria:

 Cost

 Performance

 Portability

 Animation capabilities

 User interface design

The first three criteria are general for application development whereas the second two are pertinent considering the capabilities of the ex-

20 3. OPTIONS FOR SUPPORTING MOBILE DEVICES isting Flash application, which are important criteria for applications such as Alf software.

Native Cost Highest among all if developing for multiple platforms.

Performance Direct access to the device APIs thus the best performance.

Portability For one platform only – no portability.

Animation capabilities Can be difficult to create advanced animations.

User interface design Easy to develop native UI elements, but more difficult to create custom design. Web Cost Low, many experienced people and single codebase.

Performance Performance varies and depends on the performance of web browser. Lower performance than native. Portability Single code base, minor inconsistencies between browsers. Portability beyond mobile platforms. Animation capabilities Decent support in CSS or JavaScript, many open-source libraries available. User interface design Easy to develop custom design, UI frameworks available for native look and feel, many experienced people. Hybrid Cost Low because of single codebase, similar to web.

Performance Similar to web, but depends on the performance of the WebWiew available on the specific mobile platform. Portability Single code base, many platforms supported, some code may need to be written natively. Animation capabilities The same as for web. Decent support in CSS or JavaScript, many open-source libraries available. User interface design The same as for web.

21 3. OPTIONS FOR SUPPORTING MOBILE DEVICES

Native cross-platform Cost Low in terms of single code base, but relatively new tech- nologies implying less experienced people. Performance Can achieve almost native performance.

Portability Medium portability, most important platforms usually available, but usually need to write some native code. Animation capabilities Usually week support similar to native, but varies from one technology to another. User interface design User interface is usually native – easy to design native look and feel, but harder to create custom designs. Flash-based approaches Cost Low, single codebase, easier transfer from Flash.

Performance Low, not reliable (except of AIR).

Portability Depends on the technology, usually good cross-platform support. Animation capabilities Flash excels in animations.

User interface design Easy to create custom UI, similar experience to graphics software, many experienced people. Difficult to create native UI elements.

Table 1: Summary of different approaches for mobile applications development

Web technologies were chosen to develop the new version of Alf software and the disadvantages stated in the table above are not significant for the new application. The decision was made before writing this thesis and several of the described technologies, especially Flash-based ap- proaches, were taken into consideration. HTML, however, was chosen mainly because of its broad support on mobile and, importantly, on desktop operating systems as well. Furthermore, it is easy to connect a new web ap- plication into the existing ecosystem of Test Database and Online Testing. The remaining chapters of this thesis are dedicated to the development of the new HTML5 web application.

22 4 Web Technologies

The World Wide Web from its inception in 1989 [51] followed a long path and has become a huge ecosystem for building applications that reach an incredible amount of users worldwide. It is nowadays one of the main plat- forms for building applications. Web technologies evolved and are pushed forward everyday by browser vendors, Internet-based businesses and de- velopers. The Web is still considered to be an open platform under the eyes of bodies like W3C (World Wide Web Consortium), which takes care of the standardization of web features. There are a wide range of different web technologies, each with its own purpose. The essential parts of the web stack are HTTP (HyperText Transfer Protocol), HTML (HyperText Markup Lan- guage), CSS (Cascading Style Sheets) and JavaScript. These technologies are well covered in many publications, so in this chapter focuses on several new features, or features especially important in the transition from Flash tech- nology. The open nature of the web has its costs. Browser vendors are respon- sible for implementing the web standards (formal ones or de-facto stand- ards) in order to enable the developers to use the features. Despite their good intentions, they often fall behind in support for many features making it a long process for a feature to be widely available. When browser support is referred to in this chapter, a website Caniuse.com [52] is used as a refer- ence.

4.1 HTML5 There has been a lot of information written about HTML, so it is not neces- sary to repeat it again here. This section includes just a few words and some links for further reference. HTML is a markup language to describe the structure of web pages. It is standardized under W3C and this standard is then implemented in browsers to provide a platform for web pages and their developers. As the title of this section suggests, the 5th version of the standard is covered here – the most current version at the time of writing.

23 4. WEB TECHNOLOGIES

Figure 4: The W3C HTML5 logo35

Whereas HTML is a markup language, the term HTML5 usually re- fers to a number of related technologies. New HTML5 features can be divided into three main categories: those connected with markup, styles and scripting [53]. The new standard was formed by WHATWG (Web Hypertext Application Technology Working Group), which includes experts from browser vendor companies. The following sections describe several HTML5 features useful for transition from the Flash platform.

4.1.1 Canvas HTML5 introduces a new tag designated for programmatic draw- ing in browser. It is a rectangular area, by default, with no border and no content. Canvas element provides API for creating rectangles, arcs, lines or curves and it is an essential element for creating HTML games.

4.1.2 Audio and Video Another important feature is a support for embedding media – audio and video – in a web page without any third-party plugins – e.g. Flash Player. Media can be embedded via corresponding

 H.264

 WebM

 Ogg

35 http://www.w3.org/html/logo/

24 4. WEB TECHNOLOGIES

Currently, H.264 seems to be the most promising as it is supported in all the latest browser versions. If the application needs to support older browsers, video can be served in multiple formats and the browser chooses the one it supports. HTML5 audio and video features not only enable embedding audio and video on a web page, but also include the JavaScript APIs for controlling the playback, changing tracks or videos and setting the volume.

4.1.3 Other Features The aforementioned features are not all that HTML5 brings. It includes several features which I do not consider to be essential for the process of transition from Flash, though they can be helpful. I am stating some of them just for an overview:

 Semantic elements

 New form elements

 Drag & drop

 Geolocation

 SVG (will be covered later)

4.2 CSS3 While HTML specifies the structure of the pages, we want them to be visu- ally attractive. This is the task of CSS. It is a set of rules for a web browser how to visualize HTML elements. Just as with HTML, CSS is well covered in many publications [54], so I am including just the part which I consider to be important in transition from Flash.

4.2.1 Transformations CSS3 introduces a way how to change element’s 2D or even 3D geometry – with transform property. This is very important property when creating games or some dynamic content. The value of the property is set via several CSS functions available and changes these attributes:

 Scale

 Rotation

 Skew

 Position

25 4. WEB TECHNOLOGIES

CSS transformations include several related CSS properties, which configure the actual transformation, axis and 3D perspective. Three dimen- sional transforms can also use GPU hardware acceleration, which is valuable on slower mobile devices.

01 .card { 02 transform: scale(0.31); 03 }

Example 1: Usage of CSS transform with scale

4.2.2 Transitions A transition in CSS is just an automatic animation that takes place when a CSS property’s value changes. It does not work on all the CSS attributes, but on almost any attribute useful to animate, including transform with its inner functions, such as rotate() or translate(). Transitions are usually used to create simple animations. With transition we can configure the animation per CSS property, setting the duration, delay and timing function of the animation.

01 .item { 02 /* each change of opacity CSS property is animated */ 03 transition: opacity 150ms; 04 }

Example 2: Usage of CSS transition animating the opacity CSS property

4.2.3 Animations Transitions are a simple way how to create animations with CSS. However, if we need finer control of the animation, we have to use another great fea- ture of CSS3 with describing name – CSS3 animations. They are defined with special @keyframes CSS rule, which can be seen in the Example 3.

01 @keyframes bounce { 02 0% { transform: scale(1.04)} 03 30% { transform: scale(0.97)} 04 50% { transform: scale(1.02)} 05 70% { transform: scale(0.98)} 06 90% { transform: scale(1.005)} 07 100% { transform: scale(1)} 08 }

Example 3: CSS animation definition via @keyframes rule

This bounce animation can be then reused multiple times in different CSS rules, as shown in the Example 4.

26 4. WEB TECHNOLOGIES

09 .bounce-elem { 10 animation: bounce 0.7s; 11 }

Example 4: Usage of CSS animation

4.2.4 Other Features CSS in version 3 brings many more features than described here and they are beyond the scope of this thesis. You can find a reference in a book [54], or a very good source of information is the Mozilla Developer Network [55]. While not going in detail, I consider the following features as useful in de- signing modern web applications:

 Visual enhancements like gradients, shadows or rounded corners

 Font enhancements

 Media queries for defining styles depending on device features

 New selectors

 Improvements in layout design

 Enhancements in color definitions

4.3 SVG Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics. The SVG specification is an open standard devel- oped by the W3C since 1999. For a long time, the web only supported bitmap graphics either as JPEG, PNG or GIF files. In lots of cases bitmap graphics can be limiting as it loses quality when it is zoomed or resized. Vector graphics resolves this is- sue and SVG is the format supported in browsers. SVG can be loaded from file (in tag or as a background of an element) or it can be embedded directly in HTML markup, as shown in Example 5. It is slowly, increasing in popularity on the web and it provides an alternative to vector support in Flash. SVG also comes with support for in- teractivity and animation, though this is currently not supported in Internet Explorer.

27 4. WEB TECHNOLOGIES

01 02 03

My first SVG

04 05 06 07 08

Example 5: SVG inside of a HTML markup

4.4 JavaScript The web ecosystem would be useless without any scripting and this is the role of JavaScript. It enables us to provide interactivity in our web applica- tions, respond to user input, asynchronous communication, DOM manipulation, etc. Due to its name, it is often a source of confusion about its relation to the Java programming language. However, this similarity in its name was chosen only for marketing purposes. JavaScript was introduced by Netscape in its browser in 1995. The language was developed under the name Mocha, released in beta version as LiveScript, but later renamed to JavaScript. However, JavaScript is not the official name today. The language is standardized by ECMA International36 since 1997 under the name ECMAScript [6], currently in version 5.1. It is of- ten referred to as just ES followed by a version number.

Figure 5: JavaScript community logo37

JavaScript is dynamic, interpreted programming language. It incorpo- rates multiple programming paradigms such as object-oriented, imperative and functional. JavaScript uses prototype inheritance while many other ob-

36 http://www.ecma-international.org/ 37 https://github.com/voodootikigod/logo.js

28 4. WEB TECHNOLOGIES ject-oriented languages use class inheritance, but this can be simulated by prototypes. Although JavaScript is the programming language in browsers, it en- joys increasing popularity in various other environments from servers to small embedded devices. On the server side, there are important platforms like Node.js38 or lately its fork io.js39. JavaScript was awarded as the programming language of 2014 by TIOBE Index [56].

4.4.1 Modules It has been long since JavaScript was used to validate HTML forms and popup menus. Nowadays, it is used to build large-scale web applications and these require more advanced approaches. One of them is creating mod- ules – the ability to structure the application into modules and specify dependencies between them. Unlike Java, which has packages and C#, which has namespaces, JavaScript has several different options for code sep- aration – grouping into modules is one of them. JavaScript has several different module formats available [57]:

 AMD (Asynchronous Module Definition)

 CommonJS

 UMD (Universal Module Definition)

 ES2015 modules

It is out of the scope of this thesis to describe each of these in detail. Just note that each format has its own advantages and disadvantages, and its own purpose. There are more formats because they were developed by the community and are not part of the language. The only exception is the last one – ES2015 modules – which is a part of the new language standard. It is covered in the following section.

4.4.2 ECMAScript 2015 As already mentioned, ECMAScript is the name of JavaScript used in its standard. The latest version, which achieved ratification in June 2015, is called ECMAScript 2015 (ES2015), previously referred to as ECMAScript 6 (ES6). It introduced significant updates to the language. 2015’s version is the first major update since 2009 when the version 5 was released. As Nicholas Zakas states in his book in progress: “The exciting thing about ECMAScript 6 is that all of these changes are geared towards prob-

38 https://nodejs.org/ 39 https://iojs.org/

29 4. WEB TECHNOLOGIES lems that developers are actually facing.“ [58] ES6 was developed with the real problems in mind. Among many useful new features [59] the following sections describe those I found the most important in everyday use.

Classes ES2015 introduces class definitions with inheritance as we know them from other object-oriented languages. However, the keywords for visibility (pri- vate, public, protected) are not supported yet.

01 class Shape { 02 constructor(x, y) { 03 this.x = x; 04 this.y = y; 05 } 06 07 logInfo() { 08 console.log('X:' + this.x + ', Y:' + this.y); 09 } 10 } 11 class Circle extends Shape { 12 constructor(x, y, radius) { 13 super(x, y); // parent constructor 14 this.radius = radius; 15 } 16 17 // override method 18 logInfo() { 19 console.log('X:'+this.x+', Y:'+this.y+', R:'+this.radius); 20 } 21 }

Example 6: Classes support in ECMAScript 2015

Arrow Functions Functions in JavaScript cause a lot of confusion around the value of this in- side the function [60]. The value can be changed manually and may differ from the value aimed at definition. It can be seen inside DOM native event handlers and can act as a cause for software bugs. Arrow functions in ES2015 intent to help with this issue. They repre- sent a new syntax for defining functions and have value of this bound to the definition . The syntax (with arrow) is similar to lambda expres- sions40 in C# or Java.

40 Anonymous functions or functions that are not bound to an identifier.

30 4. WEB TECHNOLOGIES

01 var button = { 02 label: 'Click me!', 03 04 init: function () { 05 document.addEventListener('click', (event) => { 06 console.log(this.label); // prints 'Click me!' 07 }); 08 } 09 };

Example 7: Arrow function in ECMAScript 2015

Template Strings Strings in JavaScript, prior to ECMAScript 2015, had not supported multiline definition and had no built-in feature for strings interpolation. This is intro- duced in ES2015 and reduces the need for string concatenation.

01 var name = "Bob" 02 var time = "today"; 03 04 console.log(`Hello ${name}, how are you ${time}?`); 05 // Hello Bob, how are you today?

Example 8: Template string in ECMAScript 6

Modules Multiple JavaScript module formats were mentioned in section 4.4.1. How- ever, ES2015 tries to unify the syntax for defining and loading modules in JavaScript. It moves the need for modules into the language itself, possibly to replace other existing approaches.

01 import $ from 'jquery'; 02 03 function sayHello() { 04 $('#myDiv').text('Hello World!'); 05 } 06 07 export default sayHello;

Example 9: ECMAScript 2015 modules syntax

Enhanced Function Parameters JavaScript, in ES2015, receives several new features related with function parameters:

31 4. WEB TECHNOLOGIES

 Default parameters – An option to provide a default value for a parameter and mark it as optional.

 Rest parameters – A last parameter if preceded by three dots (…) becomes an array containing the rest of the parameters.

 Spread operator – Similarly to rest parameters, it is a three dot operator which expands an array argument into separate argu- ments when calling a function.

Browser Support and Compilers ECMAScript 2015 brought many important features, but as with other web technologies, browser vendors are those responsible for availability of the features in browsers. Developers have to wait for web browsers to imple- ment the feature or they can use some kind of polyfill41. With ES2015 the options go beyond and developers can use compilers to turn code authored in ES2015 into ES5 (those compilers are sometimes referred to as transpil- ers42). There are two major players in the field described in the following sections.

Traceur The first option is a compiler developed by Google called Traceur43. It is dis- tributed as a CLI (Command Line Interface) tool, but it has a lot of plugins for build systems or IDEs (Integrated Development Environments). Not only has Traceur a good support for ES2015 features, but also supports some ex- tra features from the ES2016 proposal and goes beyond, supporting types and annotations, which are not part of any proposal. It is open-source avail- able on GitHub.

Babel Another open-source compiler is Babel44, formerly 6to5. It is very similar to Traceur in terms of CLI tools, IDE integration or plugins, just it offers more options. Importantly, aims at producing a readable code. Also, it has slightly broader ES2015 support, though both tools support the most essen- tial features. Just like Traceur, Babel also handles several experimental fea- tures from ES2016 or beyond. With the latest release, Babel experienced a major rewrite and became more modular claiming to be a universal platform for transpiling JavaScript [61].

41 A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that the developer expects the browser to provide natively. 42 Transpiler or transcompiler is a source-to-source compiler. 43 https://github.com/google/traceur-compiler 44 https://babeljs.io/

32 4. WEB TECHNOLOGIES

4.4.3 Single-Page Application Frameworks In the recent years, there has been an increasing trend of so-called Single- Page Applications (SPA). These are web applications which consist of one HTML page and all the behavior is taking place on the client side in browser. This reduces the payload between the client and the server as the application runs without a full page reload. Consequently, it improves the user experience as the application is more responsive. This approach also reduces processing on the server and moves it off to the client’s hardware. There are lots of frameworks which help us develop server-side applications like Ruby on Rails, Symfony, Laravel, Struts, ASP.NET etc. Similarly, lots of frameworks were created in order to help with developing modern SPA applications. These frameworks are called Single-Page Appli- cation frameworks, or sometimes just client-side frameworks as opposed to the server-side ones. Additionally, those frameworks are often grouped as MV* frameworks, as they are usually based on some variant of MVC (Model-View-Controller) architecture. Since the trend of Single-Page Applications has started, a lot of frameworks have appeared. In fact, hundreds of frameworks exist to solve various aspects of SPA development. Almost any company developed its own solution that fits their needs. A website called TodoMVC45 shows the comparison of the different frameworks as it offers the same Todo applica- tion implemented in most of the popular frameworks. Currently, it offers 64 applications. In the following sections, two major players on the field of SPAs are described. They were chosen according to the DailyJS survey [62] and according to the number of stars on GitHub [63].

AngularJS AngularJS [64; 65], or just Angular, is the most popular SPA framework ac- cording to the references mentioned. It was made at Google and open- sourced. Angular is considered to be a full-featured SPA framework offering features across most of the SPA development areas. It offers models, views, controllers, routers, HTML templates, module system, dependency injection (DI), UI widgets and a lot of plugins. It focuses heavily on the separation of con- cerns and testability.

Backbone Another popular JavaScript framework is Backbone (or Backbone.js) [66; 67]. It is sometimes treated just as a library because it is very lightweight (only several kilobytes of code). It does not offer a lot of features, but rather acts as

45 http://todomvc.com/

33 4. WEB TECHNOLOGIES a backbone for a SPA application (thus the name). It offers views, models, col- lections, routers and an event system. As Backbone is very small and simple it is easy (and recommended) to extend with our own features and communi- cates well with other libraries of our choice.

React.js Although, it is not a full SPA framework, I believe it is worth to mention here as it brought a revolution into the web application development. React.js is only a View part of MVC or MV* architecture. It may be used standalone with custom application architecture or even together with other SPA frameworks as the View part. Its revolutionizing feature is the Virtual DOM. The framework maintains a DOM image in memory and when changes are to be rendered, only the difference between virtual and real DOM are rendered. This leads to a significant increase in performance. The Virtual DOM is a very important invention and is now being used in many SPA frameworks.

4.4.4 Testing Testing is one of the essential parts of software development. Via testing we validate software whether its behavior is as we expect. There are several types of testing, used at several stages of the project, but this section covers automated testing in JavaScript. Through automated tests not only can we validate software, but also safely enhance it in the future, without worrying about breaking the existing features. Automated tests are commonly present in software projects. With the advancement of the web platform and the emergence of rich JavaScript applications, we can see significant growth in usage of automated tests in JavaScript. The most common automated tests are unit tests. In JavaScript there are three main test frameworks or libraries for unit tests:

 QUnit – The oldest one on the market, developed by the jQuery Team.

 Jasmine – Supports more types of assertions and it is easy to configure.

 Mocha – The newest, most extensible and very similar to Jasmine. Its main advantage is a good support for testing asynchronous code.

In order to run the tests we need a test runner. Some of the test frameworks include a runner or we can run the tests via Karma [68]. It runs them in multiple browsers at once, making it very convenient to test the code for any

34 4. WEB TECHNOLOGIES inconsistencies in different environments. Karma is open-source and was developed by Google mainly for testing Angular applications, but it is not limited only to Angular.

4.5 Build A web application consists of various resources like HTML pages, CSS files, JavaScript files, images, fonts, and possibly more. When a browser wants to run such web application, it has to download all the files from the server. Browsers use the HTTP protocol to retrieve a data from the server and they must make one HTTP request per resource. As a consequence, this produces a large overhead over the network connection. We can improve our web applications by reducing the number of files and furthermore, reducing their size by removing spaces and blank lines. Despite being possible to do this manually, it is not a good practice as it de- grades the maintainability. In this situation, build tools come in handy. They provide a way to optimize an application before it goes into production, whilst enabling the developer to maintain a modular structure during de- velopment. With build tools we can concatenate CSS and JavaScript files, minify them as well as HTML files, but the build process can go beyond that. We can run tests, check the code style or compile ES2015 code into ES5 (Section 4.4.2) during our build and do many more tasks specific for our project. In JavaScript’s world, there exist two major build tools – or better to say task runners – Grunt46 and Gulp47. The former uses configuration over code approach, while the latter uses the opposite. However, they are very similar as the following holds for both:

 Hundreds of plugins available

 Build process and plugins are configured in a JavaScript file

 Solid IDE support and integration

Using a build tool, or a task runner, is a recommended practice dur- ing development of modern web applications – even more important for Single-Page Applications (Section 4.4.3). It can automate repetitive tasks and help during development, or optimize the application for production and thus improve the user experience.

46 http://gruntjs.com/ 47 http://gulpjs.com/

35

5 New Alf HTML5 Application

HTML5 is a powerful technology which has become even more important with the arrival of devices such as smartphones & tablets. Its support and reach makes it a favorite choice for developers. This chapter describes a process of transition from the Flash version of Alf software described in Chapter 2 to a new HTML5 application using standard web technologies mentioned in Chapter 4. The term Alf HTML5 application or simply just Alf HTML is used interchangeably.

5.1 Requirements The first step in the process of building software is specifying the require- ments. Two types of requirements – functional and non-functional – for the new Alf HTML5 application are described in the following sections.

5.1.1 Functional Functional requirements focus on the functionality of software. We usually visualize these requirements with a use-case UML (Unified Modeling Lan- guage) diagram, but with Alf HTML it is not that important. We can rather refer to the existing Flash version for our functional requirements and the new HTML application should try to imitate the old one. The test creation part is excluded from the requirements, so we focus only on displaying the tests. It can be referred to as a test player. The users of the application are teachers and students. Teachers when they preview the tests offered in the Test Database, students when the teach- ers assign the tests via Online Testing portal. The functional requirements for Alf HTML can be summarized into the following list:

 The application has to open tests in the format created in the Flash version of Alf software.

 All types of tasks and all test configurations have to be supported.

 The tests are to be retrieved from the Test Database and Online Testing.

 Teachers can preview the tests offered in Test Database.

 Students can sit the tests that they have been assigned in the Online Testing portal.

37 5. NEW ALF HTML5 APPLICATION

 Their results have to be sent back to the Online Testing portal for teachers to be able to see them.

Apart from the above mentioned requirements which replicate the requirements for the Flash version, there is one extra requirement. When the customer – Interaktívna škola s.r.o. – decided to make a transition from Flash to HTML5, they wanted some additional added value. Therefore, there is the extra requirement:

 Alf HTML should be able to capture detailed students’ answers and then reconstruct the answers for teachers’ preview.

5.1.2 Non-functional Non-functional requirements are about properties and constrains on the software or on the development process. They often apply to the system as a whole. Examples of such requirements are reliability, scalability, security, performance etc. For Alf HTML, these are the main non-functional requirements:

 Operate on mobile devices as well as in the desktop environment.

 Behave consistently across supported browsers.

 Give similar user experience to the previous Flash version.

 Avoid performance degradation on less powerful mobile devices.

 Use existing authorization policy provided by the Test Database and Online Testing.

5.1.3 Browser Support The term – supported browsers – was used and consequently we need to define which browsers are meant to be supported by Alf HTML. It is reason- able to support the browsers with the highest usage. We can refer to services that provide statistics about global browser usage or even for a specific country – specifically StatCounter48 and NetApplications49. However, an even more relevant source of browser statistics is the analytics used on the existing web portals related to the Alf software. The browser usage distribu- tion can be seen on Figure 6. The following six browsers accounted for over 99% of total usage, so limiting support to these made sense:

48 http://gs.statcounter.com/ 49 https://www.netmarketshare.com/

38 5. NEW ALF HTML5 APPLICATION

 Mozilla Firefox

 Microsoft Internet Explorer

 Android Browser

 Opera Browser

 Apple Safari

Figure 6: Browsers’ usage distribution on the web portals related to Alf software

When the supported browsers are defined, we need to define also the particular browser versions. In all the major browsers we claim to support, except of Internet Explorer (abbreviated IE) and Android Browser, there is an automatic update mechanism, so we need to focus only on the latest ver- sions. In terms of version support for the Android Browser, Alf HTML should support version 4.0 and higher. Choosing the lowest supported version of Internet Explorer is a well- known topic. It is an important decision from the development point of view as the older versions lack some web features useful for building modern web applications. Statistics from the Alf web portals (Figure 7) show us the distribution of IE versions. We can afford to support only the latest version 11 as the other versions represent only 3.58 % of the overall website usage. Although, some companies tend to support browsers with such usage level, for Alf HTML not supporting them can bring significant advantages. This decision affects the development and makes it much easier as we can use the latest web technologies and standards.

39 5. NEW ALF HTML5 APPLICATION

Figure 7: Usage of Internet Explorer versions on the web portals about the Alf software

5.2 Analysis and Design After the requirements are defined, we move to the software analysis. Part of that is included in Chapter 3, but that is related to the various methods of supporting mobile devices and their comparison. This section describes only the analysis & design of the new web application. First thing needed to analyze was the original Flash version of the Alf software to identify the main characteristics and functionality that might cause problems in HTML. The test creation was excluded from this analysis as it is not required in the new HTML version. From the engineering per- spective the following key parts of the application were identified:

 Home page

 Displaying the test, which includes:

o Intro page

o Specific tasks

 Application settings

An important consideration in this phase of software development was to choose the right technologies for the project. Usually, choosing an applica- tion framework has an influence on the architecture. Further analysis & design was performed in the following three phases:

1. Analysis of the available client-side frameworks.

2. Prototypes in multiple of them.

3. Architecture design influenced by the chosen framework.

40 5. NEW ALF HTML5 APPLICATION

Creating prototypes is time consuming, even more if we create multiple prototypes. However, it is a very powerful way how to discover advantages and drawbacks of each approach specifically related to our project. This is why around 2 months’ time was invested to do the analysis and prototyp- ing.

5.2.1 Client-side Frameworks Analysis Web frameworks and technologies which are mentioned earlier in this thesis were analyzed. As the new web application was to be highly interactive and animated, the main focus during this analysis was on how the framework deals with animations. Similarly important was the extensibility and con- nection with other modern web development tools and software libraries. The following technologies were chosen to put forward to the proto- typing phase:

 Adobe Edge

 Google Web Designer

 Backbone.js

 React.js

Angular was considered as well, but it provides far more features than re- quired for Alf HTML. It did not require complex routing, no data updates from the server or common widgets. Therefore, a prototype was not devel- oped in Angular.

5.2.2 Prototyping Alf task Order (horizontally) was chosen to be developed for prototyping purposes. It is not very complex, but at the same time, contains features used across multiple tasks like drag & drop or multimedia object (box which can contain text, image and audio). As some of the technologies proved not to be suitable in the early phase, not all of the prototypes were developed to the same extent. They are described in the following sections in the chronologi- cal order.

Adobe Edge Adobe Edge was the first choice as it seemed to provide a Flash-like devel- opment experience, very useful for developing animated applications. A fully working prototype was developed, several problems occurred. This was the reason why Adobe Edge was not used to implement the whole ap- plication. Although, Edge excels in animations, it was hard to connect it to

41 5. NEW ALF HTML5 APPLICATION other tools, libraries or use modern web development practices like modules or ES2015. Adobe Edge creates several files to be used in the HTML page. One of them is a configuration containing all the information about the element styles, positions, timelines, etc. Second one is a file with actions – behavior which you add to elements or on to the timeline. Then it uses a special runtime to power the HTML pages, which processes the configuration and actions and is capable of creating timelines, animating elements and so on. The problem is that the configuration and action files have proprie- tary formats and are not easy to edit manually. Even though Adobe claims that the actions file is editable, I experienced multiple times that the project was broken because of invalid format of the actions file. Moreover, during the writing of this thesis, Adobe announced no further development of Adobe Edge tools [69]. This justifies that the decision not to use Adobe Edge was correct.

Google Web Designer Google Web Designer seemed to be another promising tool, but it was re- jected in the early stage. It provided better extensibility than Adobe Edge as it operates on a normal DOM and no special actions or timeline configura- tions are constructed. On the other hand it offers far fewer options than Adobe Edge and was not beneficial enough for this project. Therefore, the prototype was not created and the Alf task was not implemented in Google Web Designer.

Backbone.js The reason Backbone was chosen among other SPA frameworks was be- cause it is very simple yet still powerful enough for the needs of Alf HTML5 application. Comparing to the previous technologies, it offers no animating features, but is very extensible, which enables us to use any JavaScript li- brary for animations of just CSS3 features. Back in time before the prototype with Adobe Edge was started, using CSS3 or a JavaScript to manually create animations seemed like a difficult task. But later, when working on a proto- type with Backbone.js, this approach turned out to be simple, causing few problems. The most advanced prototype out of all was made with Backbone.js. It showed how easy it is to integrate it with other tools & libraries. Specifi- cally, the library called Sortable was used in the prototype to quickly implement ordering of the letters or words in the Order (horizontally) Alf task. This prototype was then presented to the client in September 2014, be- fore the actual development was started.

42 5. NEW ALF HTML5 APPLICATION

React.js Backbone.js seemed promising after the prototype was developed. However, React.js was new and very innovative library for building UIs and thus it was investigated whether it could be beneficial for this project. After all, it can be used together with a full SPA framework, including Backbone.js. So, another prototype, now with React.js, was created. This prototype reused a lot of code from the previous Backbone.js prototype, so it was only a quick test if the library is suitable. While React excels in UI rendering and offers high performance, it did not have significant effect on our new Alf HTML Application. Its UI does not need to be re-rendered or partly re-rendered based on the data that has changed. Moreover, React did not have a good support for animations, the crucial part of Alf software. As a consequence, React was not used in the implementation phase.

5.2.3 Architecture After the prototypes were finished and Backbone.js was chosen as the appli- cation framework, the next step was to design the architecture of the new Alf HTML application. At first, the overall system architecture was designed, which defines how the application is divided into the server and client side. Next, the REST service on the server was designed, followed by the architecture on the client – the architecture of the Single-Page Applica- tion. One of the key parts of the architecture was accessing data from the tests. As Alf HTML application should be able to display the tests from the Tests Database, it needs to access them. The tests are stored on the server in the proprietary format used in the Flash version of Alf software. To access them from the new HTML application, there were two approaches possible:

 preprocess the tests on the server and prepare better data structure for the client-side

 let the client-side Backbone application to access the original test format directly and process it on the client

The first option to keep the parsing and processing on the server was chosen mainly because it:

 saves some computing power on the user device

 gives an extra layer of flexibility

 can produce easy-to-process JSON (JavaScript Object Notation) format

43 5. NEW ALF HTML5 APPLICATION

The communication between the server and client is described in Figure 8. The server responds to two types of requests. At first, it sends the static assets (HTML, CSS, JavaScript, images etc.) and then provides a REST endpoint to send the data for the test in JSON format.

Figure 8: The overall architecture of Alf HTML5 application

The UML Deployment Diagram in the Figure 9 shows the distribution between the client and server as well as additional communication with Online Testing. It is described later in this section.

Figure 9: Deployment diagram for Alf HTML

Usage of REST services is very common nowadays, especially if the data from the server are used in multiple applications (desktop, web, mobile

44 5. NEW ALF HTML5 APPLICATION etc.). This is not the case for Alf HTML5 application as it is the only one ac- cessing that data, but REST is easy to use and it is a standard approach for Single-Page Applications.

Test Data Format The REST endpoint sends a test data in a completely new JSON format. At the root level of the JSON document we can find general test data like title, author etc. Then the tasks property contains an array of data for specific tasks. Each task contains its type, description, time, points, maxPoints and other task-specific data. A full format example is included in the source code provided along with this thesis, in the file sample_tests/test-data.json.

Communication with Test Database and Online Testing The new Alf HTML5 application is required to communicate with the Test Database and Online Testing. There are two types of communication. First, Alf HTML offers URLs (Unified Resource Locators) with parameters (de- scribed in the following section – Implementation), so that users can launch the tests directly from the user interface in Test Database (when teachers preview the tests) and Online Testing (when students sit the tests). Second, after a test is launched, Alf HTML has to call the REST endpoints provided by Online Testing in the background. It is out of scope of this thesis to de- scribe the details of this REST communication, but it is partly described in my Bachelor thesis [1]. The endpoints were slightly changed to meet the new requirements of Alf HTML, deprecating the ones used by previous online Flash version. The current ones are the following:

 /olt/www/api/alf/authorizeFile/ Prevents unauthorized access from Test Database, when teachers preview a test.

 /olt/www/api/alf/authorize/ Prevents unauthorized access from Online Testing, when students launch a test.

 /olt/www/api/alf/start/ Record the time when a student begins a test.

 /olt/www/api/alf/finish/ Records end time and detailed task answers when student com- pletes a test.

 /olt/www/api/alf/answer/ Used to reconstruct the detailed student‘s answers.

45 5. NEW ALF HTML5 APPLICATION

Unlike the previous Flash version, Alf HTML is capable of recon- structing the detailed answers, the communication was enhanced. After a student completes the test, Alf HTML sends not only the final result, but also the answers in specific tasks. This is then stored in Online Testing and sent back to Alf HTML when a teacher wants to see the student’s answers.

5.2.4 Single-Page Application After the communication between the server and client in Alf HTML was designed, the next step was to design the client-side architecture. Back- bone.js itself provides guidelines for structuring the application as it uses the MV* architecture. It gives us models, collections of models, views, and router, each corresponding to a JavaScript class in Backbone.js. In the appli- cation code, those classes are then inherited and configured. The first layer to design was the View. The hierarchy of the Views in the HTML application is designed based on the analysis of the Flash version. It is described in Figure 10. The SpecificTaskView does not correspond to an actual view. It is just a placeholder and it is to be replaced with a view spe- cific for a type of Alf task i.e. VjoView, PexView, PzzView etc.

Figure 10: Hierarchy of the views in the SPA application

The next layer to design was the Model. It contains the classes that encapsulate the data for the Alf test and the model structure is constructed from the JSON response from the server. All the classes inherit from Backbone.js classes which provide several utility methods as well as support for the event system. Other parts of the application can subscribe to events

46 5. NEW ALF HTML5 APPLICATION and be notified in case of any change in the model. The class diagram is shown on Figure 11.

Figure 11: Class diagram of the Model part of the Alf HTML5 Application

When Views and Models are designed we need a layer to connect the two. Backbone.js does not offer any Controllers from the MVC architecture. In fact, they are not needed for the Alf HTML5 Application as no routing is involved after the initial load. The only communication needed between the Models and Views is changing the displayed Alf task. This is a responsibility of TestRunner and the communication is outlined in the UML Communica- tion Diagram on Figure 12. TestView initiates the task change and it is then notified when the change was made. This one way communication ensures no accidental cascading changes are made, which makes the application de- velopment easier. This architecture was inspired by the Flux architecture [70] used for React.js applications.

47 5. NEW ALF HTML5 APPLICATION

Figure 12: Communication diagram for the task change

5.3 Implementation As described in the Analysis and Design section, the Alf HTML5 application is divided into the server and the client parts. This section describes the im- plementation details of both parts focusing on the features specific for Alf HTML.

5.3.1 Back-end The server part, or back-end, of Alf HTML5 Application is a small set of ser- vices written in PHP. The previous section describes how the data from Alf tests is loaded and one of the services is responsible for processing that data. Along with that, two more REST services were introduced while developing the front-end. Their features are described more deeply in the following sec- tion devoted to the front-end. The list of the back-end services are as follows:

 Parsing the tests and transferring them to the JSON format, which is easier to consume in JavaScript front-end.

 Logging client-side application errors.

 Slicing the images for the purpose of the puzzle task type.

48 5. NEW ALF HTML5 APPLICATION

Due to the small size of the server side logic, there was no need to use a full application framework. Only several utilities from Nette Framework50 were used to simplify class loading, handling of HTTP requests, and aid with debugging and error handling. The application logic itself consists of three classes plus one utility class:

 Parser – Parses the test file and converts it to an array in PHP.

 Extractor – Extracts data from the output from Parser and creates a new structure. TaskExtractor is used to extract data for the tasks.

 TaskExtractor – Handles the extraction for the specific Alf tasks.

 Helper – Contains helper methods for the data extraction.

5.3.2 Front-end The vast majority of the application’s logic lies on the client side – so, on the front-end. This logic is implemented in JavaScript, but there are also other languages that could be used for authoring the application code and then compiled to JavaScript (CoffeeScript, TypeScript or Java to mention a few). For Alf HTML, however, I decided to stay with pure JavaScript as it is native language in browser and has a good long-term support. The compile step is still present as ECMAScript 2015 was used, which, at the beginning of the project, was not broadly supported in browsers. But the difference between ES2015 and other languages is that web browsers are committed to support ECMAScript in the future and thus the need for the compiler will eventually disappear. The application’s logic is organized into modules. ES2015 modules syntax is used. The modules are organized into several directories, which form namespaces, according to their purpose – models, views, routers, localization, settings, etc.

Layout Scaling HTML layout can be composed in many ways. One way is responsive lay- out, where percentages are used to scale elements and CSS media queries to adapt to different screen sizes. Although, this is a very common approach nowadays especially when the mobile web has become important, Alf HTML does not make use of it – a different and very unique approach was chosen.

50 https://nette.org/

49 5. NEW ALF HTML5 APPLICATION

The layout in Alf HTML uses absolute positioning51 and static dimen- sions for DOM elements. This simplifies the positioning of elements and makes it easier to work with coordinates especially in the Alf tasks which use drag & drop. However, with absolute positioning and static dimensions, the page would be small on bigger screens or resolutions and would not fit in the window for smaller resolutions. Therefore, dynamic layout scaling was developed for the Alf HTML5 application. It is applied to the layout container and ensures the most available space of the window is used while keeping the aspect ratio of 4:3. When the window is resized or orientation of the device is changed from landscape to portrait or vice-versa, the layout always adapts. A useful tool for testing this feature is the Device Mode in Chrome Dev Tools52. We can use it to simulate the device dimensions or orientation and then change it to see how the page responds. The examples of landscape and portrait mode can be seen on the Figure 13 and Figure 14.

Figure 13: Landscape orientation in the Device Mode in Chrome Dev Tools

51 CSS property position is set to absolute (or sometimes relative) and then the element is positioned with top, left, right and bottom properties. This is the opposite of the basic positioning in HTML when DOM elements follow their order in the DOM. 52 https://developers.google.com/web/tools/chrome-devtools/iterate/device-mode/?hl=en

50 5. NEW ALF HTML5 APPLICATION

The technology behind the layout scaling feature in Alf HTML is CSS transform – scale, applied to the layout container, together with changing of the dimensions for the element. The onresize event53 is used in case the dimensions of window change. The code responsible for this feature can be found in the source code in the app/scripts/rescale.js file.

Figure 14: Portrait orientation in the Device Mode in Chrome Dev Tools

Text Scaling When a test is being created using the Flash desktop version of Alf software, each text input field has a limit on maximum number of characters allowed. However, for most of the fields it can span between a word and a couple of long sentences. Later, when the test is being displayed we need to ensure that the text is presented in a meaningful way and does not go out of win- dow. To address this, Alf HTML has text scaling in place. It is done by iter- atively lowering the font-size of the element and checking if its height is lower than a given threshold. This functionality is encapsulated in the resizer.js component, located inside the app/scripts/alf/views/helpers

53 https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onresize

51 5. NEW ALF HTML5 APPLICATION directory. For better visualization of the feature, a live example in the UI can be found on Figure 15.

Figure 15: Example of text scaling in the Multiple Choice task

Animations Animations are used in many parts of the application. They create better experience and make the application more attractive. Most of the animations involve only changing CSS properties for DOM elements. Those animations are created with an open-source library – VelocityJS54, which is very fast and provides simple API. One of the usages in the application is shown in the Example 10.

54 http://VelocityJS.org

52 5. NEW ALF HTML5 APPLICATION

01 Velocity($smiley[0], { 02 translateY: -520, 03 opacity: 0 04 }, { 05 duration: 5000, 06 complete: () => { 07 $smiley.remove(); 08 } 09 });

Example 10: Animation for smiley in Hangman task created with Velocity.js

Apart from animating simple CSS property changes, there are places where more advanced animations were required. In the following examples, a technique called Sprite55 is used. Several animation states are placed in a sequentially to one file. With this technique it was possible to create anima- tions like burning sparkler or balloon burst.

Figure 16: Timer showing the remaining time for the current task with a sparkler animation

Figure 17: Sprite containing the sparkler animation

55 In computer graphics, a sprite is a two-dimensional image or animation that is integrated into a larger scene.

53 5. NEW ALF HTML5 APPLICATION

Figure 18: Balloon burst animation in the Hangman task

Figure 19: Sprite containing the balloon burst

Drag & Drop The Flash version of Alf software makes a significant use of the drag & drop feature. There are many types of Alf tasks where user can drag some items and chose a place to drop them. HTML5 has a support for drag & drop as well, but it is not as easy to use as in Flash. The drag & drop APIs are more low level and there are many browsers with different implementations, sometimes even with software bugs. However, an open-source JavaScript library Interact.js56 was used, which simplifies the implementation of drag & drop and aligns the behavior across different browsers, especially on mobile devices. A wrapper for Interact.js API called Draggable was developed. It is configurable and provides flexible events for easy use in different types of tasks in the tests. The events are as such:

 onDragStart – fired when dragging starts.

 onDragEnd – fired when dragging ends.

 onDrop – fired when dropped in a position available for drop.

56 http://interactjs.io/

54 5. NEW ALF HTML5 APPLICATION

 onExchange – fired when dropped element should replace the previous one in that position.

 onPinned – fired when an item should go into a pinned position (used in the Matching task).

 onUnpinned – fired when an item is removed from a pinned posi- tion (used in the Matching task).

For two of the Alf tasks – Order (horizontally) and Order (vertically) – an- other drag & drop component was created called Sortable. It is based on the Draggable component, but it has support for sorting among the elements.

Picture Labeling Task One of the popular tasks within the Alf tests is Picture Labeling. However, it is described here not because of its popularity, but because of the challenges it introduced in HTML. The task, as it can be seen on the Figure 20, consists of a picture with up to 13 labels at any position and their corresponding pointers at any position as well. Those pointers have to be dynamically cre- ated when the task is being displayed.

Figure 20: Example of the Picture Labelling task

55 5. NEW ALF HTML5 APPLICATION

SVG technology was used for this feature. The line is created dynami- cally between the label and the pointer is following the right angle. The logic itself is encapsulated in the SvgSceneView, which is responsible for rendering the whole scene with labels, lines and pointers. This code can be found in app/scripts/alf/views/tasks/pob/svgScene.js.

Router URLs are one of the essential parts of the web and they are used to point to a specific part of a web application. It is natural for server side applications as the server responds to a request according to the URL. With modern web frameworks the applications may use custom mapping between the URLs and the application’s code. This is called routing. Single-Page Applications need routing as well, but the client-side routing. Most of the SPA frameworks use the fragment part of URL (the portion after the hash symbol) for routing. This ensures no request to the server is made and the change in URL is handled in JavaScript. Some frameworks support also the new History API57, which removes the need for a hash symbol in URL, but the behavior remains the same. The router used in Alf HTML, defined in app/scripts/alf/routers/ router.js, contains the following four routes:

1. A route to launch the tests from Test Database.

2. A route to launch the sample tests on the server (out of scope of this thesis).

3. A route to launch the tests from Online Testing.

4. A route to launch the reconstructed answers.

Logger When an application is developed and released to production it is important for a developer to be notified of any application errors. It is common practice for server-side applications to have a logger instance which collects errors into a file and sends an email or even SMS in case of a critical application fault. For client-side applications it is different as there are no log files in- volved and no direct access to a mail server. Therefore, a client-side logger was developed, which makes a request to the REST server endpoint in case of an error in the application. It contains only a simple log method, shown in the Example 11. This solution is inspired by Nicholas C. Zakas [71]. Logging

57 http://www.w3.org/html/wg/drafts/html/master/browsers.html#history

56 5. NEW ALF HTML5 APPLICATION into a file or email is handled by a common server-side logger. In my case it is Tracy58, part of Nette Framework.

01 var logHistory = {}; 02 03 export function remoteLog(msg) { 04 // log the same error only once 05 if (logHistory[msg]) { 06 return; 07 } 08 09 logHistory[msg] = true; 10 11 // create request via the Image object 12 var image = new Image(); 13 image.src = '../api/log.php?msg=' + encodeURIComponent(msg); 14 }

Example 11: Client-side logger

The logger is smart enough that it sends the same error message only once per application load. It maintains a history of application errors and when a new error occurs logger at first makes a lookup in the history. This feature saves a lot of traffic to the server as well as disk space on the server. It was added after the initial release when the log files started to grow quickly because the same errors were being generated in sequence.

Software Testing Testing takes place during the development of every application. Whether the testing is automated or manual, the implementation always needs to be validated somehow. The best scenario is to have automated tests in place, but a manual step is usually present at least in the stage of acceptance test- ing. For Alf HTML two types of testing was used. First, automated unit testing was used to validate the most crucial parts of the application. These tests use Mocha testing framework (mentioned in Section 4.4.4) with Chai59 assertion library and Karma test runner in order to run tests in multiple browsers. Second type of testing was manual user testing. This was done con- tinuously during development, but it was even more extensive during the

58 https://tracy.nette.org/ 59 http://chaijs.com/

57 5. NEW ALF HTML5 APPLICATION latter stages. The main focus was on cross-browser and cross-device com- patibility. The following devices and browsers were used for manual testing:

 ASUS laptop running Microsoft Windows 8.1 with the latest Google Chrome, Mozilla Firefox and Opera Browser, and Internet Explorer 11.

 Apple iMac with the latest Google Chrome and Apple Safari.

 Apple iPad with mobile Apple Safari.

 Apple iPad Mini with mobile Apple Safari.

 Apple iPhone 6 with mobile Apple Safari.

 Lenovo A7 tablet with Android 4.2.2, Android Browser and the latest Google Chrome.

 Dell laptop with touchscreen, running Microsoft Windows 8.1 with the latest Google Chrome.

 ASUS laptop running Microsoft Windows 7 with the latest Google Chrome and Internet Explorer 11.

This list of devices and browsers covers all the supported browsers, which are stated in the requirements defined in Section 5.1.3. Manual testing can be daunting at times as it is time consuming and repetitive. For Alf HTML, the testing was greatly improved by using specifi- cally two tools. One of them is the Grunt watch task60 which is able to refresh the page in browser if the source code changes. For changes in CSS files it works even without the reload, so the new styles are applied immediately. Although, it may not seem as a significant improvement in the first place, this setup becomes important when it comes to testing in multiple browsers or devices. The second tool which greatly improved cross device testing was weinre (WEb INspector Remote)61. It runs a server on the development ma- chine, which enables us to inspect web sessions running on any remote device. It provides a DOM inspector and a JavaScript console. The benefit is that weinre works regardless of the tested device, which makes it easier to set up and use than different native debugging tools for each mobile plat- form.

60 https://github.com/gruntjs/grunt-contrib-watch 61 https://github.com/apache/cordova-weinre

58 5. NEW ALF HTML5 APPLICATION

5.4 Comparison to Flash Development This section provides an overview of the differences between the develop- ment of the two versions of Alf software – the old Flash version and the new HTML5 version. The aim of this section is not to provide the full comparison of Flash and HTML development, but rather to focus on the comparison between these two specific applications. However, the ideas presented here are highly likely to apply to any software transition from Flash to HTML. Although, I am not the author of the Flash version of Alf software, I contributed with some pieces and I have good insights into the process of building it. In addition, I have a fair amount of experience in building Flash applications on a smaller scale, which makes me eligible to provide this comparison. The opinions in the following sections are based on my per- sonal experience.

5.4.1 User Interface Designing a user interface for Flash is very easy. The Flash authoring tool offers a similar experience as the graphics software, which is very easy to use for designers. Some graphics software, however, offers export to HTML as well, which may help in design of user interfaces in HTML. Additionally, there are many people experienced in the area of HTML design. HTML design, if done right, can give much better maintainability be- cause visual styles are separated in the CSS files, can be reused and are easy to change.

5.4.2 Animations In terms of animation, Flash wins with its timeline as it is easy to design and prototype animations. It is useful for designers when they do not know ex- actly what animation they want to use. Animating in HTML involves multiple technologies and practices. Alf HTML5 application makes use of CSS3 animations, transitions, Velocity.js JavaScript library, and sprite images. Although, it is possible to produce the same the same animations in both technologies in HTML it usually requires more effort. Regarding performance both Flash and HTML have their pros and cons. Flash can have smooth animations, while HTML can be less perfor- mant with the same animations in some browsers. However, HTML’s performance varies from browser to browser and from device to device. It can achieve very high performance, for example in Google Chrome.

59 5. NEW ALF HTML5 APPLICATION

5.4.3 Drag & Drop Flash offers powerful drag & drop API and many Flash applications, or games especially, make use of this. There is collision detection available in the basic API. On the other hand, the basic drag & drop API in HTML is not power- ful enough, not extensible and behaves differently across browsers. That is why for Alf HTML a custom drag & drop solution was developed. The vast array of available JavaScript libraries greatly helps with developing HTML applications using drag & drop features.

5.4.4 Audio Flash has always excelled in multimedia – audio and video. However, HTML these days also has lot to say. The support for

5.4.5 Optimization It is hard to compare both technologies on how optimized the produced outputs are. It can vary from one application to another. However, for Alf software the HTML version is far more optimized than its Flash predecessor. The Flash SWF file for Alf software is 2.1 MB in size, whereas the total size of all the assets needed for the Alf HTML homepage is only 746 KB. This leads to faster download time. The general load time is cut down in HTML also due to the fact that no additional progress bar is present as in the Flash ver- sion.

5.4.6 Compatibility and debugging Flash with its aim to enable developers to write code once and run it consist- ently everywhere is valuable. It offers a comfort in development and short- ens the time of the software validation. However, Flash is not available everywhere, which is why this thesis was created. With HTML it can prove to be difficult verifying the functionality in various browsers across various devices and it is not even possible to cover the whole market. There are some tools available, which may greatly help with cross-browser testing as mentioned in the Software Testing section. Importantly, browsers have evolved and there are far fewer differences to- day than there used to be. Also, most of the modern browsers use the auto update mechanism, which ensures users get bug fixes and new features quickly. One of the most significant advantages of HTML, when comparing to Flash, is the availability of powerful development and debugging tools. The

60 5. NEW ALF HTML5 APPLICATION state-of-the-art developer tools in Google Chrome offer advanced profiling mechanisms, rendering tools and a lot of other insights into how the appli- cation is rendering and performing. Other browsers are not far behind.

61

6 Conclusion

The decline of Flash on mobile devices influenced the whole industry of software development. Many companies, who bet on Flash, now have to shift from Flash and find other ways of software development. The ultimate goal of this thesis was to describe the process of manual transition from Flash to HTML5 for a particular non-trivial Flash applica- tion. This transition was successful and the HTML5 version of Alf software was released into production in September 2015. It obtained a lot of positive feedback, but, what is even more impressive is that the majority of users did not spot a difference after the transition. This proves the success as the new version achieves almost an identical user experience to the previous one. Standard web technologies, chosen for the implementation of the new application, were a good choice and did not cause any major issues. Perfor- mance of the application was validated and shows that the web technologies in 2015 are ready for development of non-trivial applications. Even if Flash has its advantages and undoubtedly played an im- portant role in the development of applications for web or beyond, the fu- ture of HTML is promising. Therefore, it is invaluable that the Alf software made a step from Flash specifically to HTML5. It opens many doors for fu- ture development which are described in the following section.

6.1 Areas for Further Development Alf software is a long running product and the owner Interaktívna škola s.r.o. has plans for future development. The first area, which comes to mind, is that the test creation part of Alf software was not included in this thesis and has not been developed in HTML yet. Teachers still have to use the desktop version to create tests. It is not a major limitation for them as even the online Flash version did not contain the test creation part. But in today’s world where everything is going online, live, instant and real time this is definitely an area for future opportunities. Developing the test creation part in HTML is planned for the coming years. Alf HTML introduced a very valuable extra feature of saving and displaying of the students’ answers. This creates almost unlimited possibili- ties for visualization of the results, answers and statistics. That can be very beneficial for teachers, and some statistics have already been implemented into the Online Testing portal. Apart from possibilities for future development in the systems around Alf HTML, there are several features planned for the application itself. One of them is the ability to move between tasks inside tests, go back

63 6. CONCLUSION within the test and the possibility to change the answers before submitting the whole test. Currently, Alf HTML, like the Flash predecessor, supports only linear traversal through the test, from the start to the end. Another, and I believe very interesting, innovation would be to incor- porate distributed testing in the classroom when a teacher shares a URL or some token with students. Then they follow the test task by task and the teacher can present their answers on the interactive board instantly while the students submit their answers for specific tasks. A similar approach is offered by the online tool called Kahoot!62. The areas where educational tools such as Alf software can improve and innovate are uncountable. Information technology has a big influence on the educational process nowadays and it will only play a larger role in the future. It is interesting to see the younger generation growing up with tablets and other mobile devices around. Using such devices and technolo- gies is natural for them more than it has ever been for any other generation. This is why the transition from Flash to the modern HTML5 is an important step for Alf software and places it on the right path for further development.

62 https://getkahoot.com/

64 References

[1] RUSNÁK, Marián. Online testing of students using the Alf database [online]. Brno, 2013. [cit. 28. March 2015]. Available from : https://is.muni.cz/th/374161/fi_b/. Bachelor thesis. Masaryk University, Faculty of Informatics. [2] Program Alf [online]. © 2011-2015, Interactive School, s.r.o. [cit. 28. March 2015]. Available from: http://programalf.com/ [3] Buy Online. SWiSH Max4 - The Ultimate Flash Creation Tool [online]. © 1999-2015, SWiSHzone.com [cit. 8. April 2015]. Available from: http://www.swishzone.com/index.php?area=products&product=max& tab=purchase [4] Adobe Flash CS4 Professional – What's New [online]. 14. August 2008, Adobe Systems, Inc. [cited 8. April 2015]. Available from: https://www.adobe.com/aboutadobe/pressroom/pressmaterials//cs 4_flash_whatsnew. [5] BRAUNSTEIN, Roger. ActionScript 3.0 Bible. Indianapolis: Wiley, 2010. 9780470525234. [6] ECMA-262. ECMAScript Language Specification. Geneva : Ecma International, 2011. Available from: http://www.ecma- international.org/publications/standards/Ecma-262.htm [7] SWiSH Mas User's Guide [online]. © 2000-2011, SWiSHzone.com [cit. 14. April 2015]. Available from: http://www.swishzone.com/downloads/PDFs/SwishMax4Help.pdf [8] WINOKUR, Danny. Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5. In: Adobe Featured Blogs [online]. 9. November 2011 [cit 17. March 2013]. Available from: http://blogs.adobe.com/conversations/2011/11/flash-focus.html [9] JOBS, Steve. Thoughts on Flash. In: apple.com [online]. April 2010 [cit. 9. April 2015]. Available from: http://www.apple.com/hotnews/thoughts- on-flash/ [10] Videonávody. In: Program Alf [online]. © 2011-2015, Interactive School, s.r.o. [cit. 7. April 2015]. Available from: http://www.interactivetests.net/alf/sk/podpora.html

65 REFERENCES

[11] Android and iOS Squeeze the Competition, Swelling to 96.3% of the Smartphone Operating System Market for Both 4Q14 and CY14, According to IDC. In: Press Release [online]. 24. February 2015, IDC [cit. 07. April 2015]. Available from: http://www.idc.com/getdoc.jsp?containerId=prUS25450615 [12] Android Developers [online]. © 2015, Google [cit. 15. April 2015]. Available from: http://developer.android.com/ [13] iOS for Developers [online]. © 2015, Apple Inc. [cit. 15. April 2015]. Available from: https://developer.apple.com/ios8/ [14] Windows Dev Center [online]. © 2015, Microsoft [cit. 15. April 2015]. Available from: https://dev.windows.com [15] CHARLAND, Andre and Brian LEROUX. Mobile application development. Communications of the ACM [online]. 1. May 2011, vol. 54, issue 5, pp. 49-53 [cit. 15. April 2015]. DOI: 10.1145/1941487.194154. Available from: http://portal.acm.org/citation.cfm?doid=1941487.1941504 [16] GALLO, Kevin. A first look at the Windows 10 universal app platform. In: Building Apps for Windows [online]. 2. March 2015 [cit. 19. April 2015]. Available from: http://blogs.windows.com/buildingapps/2015/03/02/a-first-look-at-the- windows-10-universal-app-platform/ [17] Guide to Universal Windows Platform (UWP) apps. In: Windows Dev Center [online]. 2015 [cit. 26. November 2015]. Available from: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx [18] RUSSEL, Alex. Progressive Web Apps: Escaping Tabs Without Losing Our Soul. In: Infrequently Noted [online]. 15. June 2015 [cit. 16. December 2015]. Available from: https://infrequently.org/2015/06/progressive-apps-escaping-tabs- without-losing-our-soul/ [19] OSMANI, Addy and Matt GAUNT. Instant Loading Web Apps With An Application Shell Architecture. In: – Medium [online]. 17. November 2015 [cit. 16. December 2015]. Available from: https://medium.com/google-developers/instant-loading-web-apps- with-an-application-shell-architecture-7c0c2f10c73 [20] Sencha Touch [online]. © 2015, Sencha [cit. 20. April 2015]. Available from: https://www.sencha.com/products/touch/

66 REFERENCES

[21] GRISOGONO, Grgur. 5 Best Mobile Web App Frameworks: Sencha Touch. In: Modus Create [online]. 3. March 2014 [cit. 20. April 2015]. Available from: http://moduscreate.com/5-best-mobile-web-app- frameworks-sencha-touch/ [22] Kendo UI [online]. © 2002-2015, Telerik [cit. 20. April 2015]. Available from: http://www.telerik.com/kendo-ui [23] GRISOGONO, Grgur. 5 Best Mobile Web App Frameworks: Kendo UI. In: Modus Create [online]. 3. March 2014 [cit. 20. April 2015]. Available from: http://moduscreate.com/5-best-mobile-web-app- frameworks-kendo-ui-part2/ [24] jQuery Mobile: A Touch-Optimized Web Framework [online]. © 2015, The jQuery Foundation [cit. 20. April 2015]. Available from: https://jquerymobile.com/ [25] GRISOGONO, Grgur. 5 Best Mobile Web App Frameworks: jQuery Mobile + Backbone. In: Modus Create [online]. 3. March 2014 [cit. 20. April 2015]. Available from: http://moduscreate.com/5-best- mobile-web-app-frameworks-jquery-mobile-backbone-part4/ [26] TAFT, Darryl K. Adobe Commits to Both Flash and HTML5. EWEEK. 2011, vol. 28, no. 17, pp. 16-18. ISSN 15306283. [27] Adobe Web Platform: Building a more expressive web [online]. © 2015, Adobe Systems, Inc. [cit. 18. April 2015]. Available from: http://webplatform.adobe.com/ [28] HARDY, Vincent. The Changing Web Platform Landscape: More Fragmentation?. In: [online]. 12. April 2013 [cit. 18. April 2015]. Available from: http://blogs.adobe.com/creativecloud/the-changing-web-platform- landscape-more-fragmentation/ [29] BRINZA, Bogdan. Partnering with Adobe on new contributions to our web platform. In: IEBlog [online]. 23. March 2015 [cit. 18. April 2015]. Available from: http://blogs.msdn.com/b/ie/archive/2015/03/23/partnering-with-adobe- on-new-contributions-to-our-web-platform.aspx [30] Adobe & HTML [online]. © 2015, Adobe Systems, Inc. [cit. 18. April 2015]. Available from: http://html.adobe.com/ [31] LABRECQUE, Joseph. Learning Adobe Edge Animate. Birmingham: Packt Publishing, 2012. ISBN 9781849692427. [32] Google Web Designer [online]. © 2015, Google [cit. 18. April 2015]. Available from: https://www.google.com/webdesigner/

67 REFERENCES

[33] GLOTZBACH, Matthew. Google Apps is out of beta (yes, really). In: Official Google Blog [online]. 7. July 2009 [cit. 18. April 2015]. Available from: http://googleblog.blogspot.com/2009/07/google-apps- is-out-of-beta-yes-really.html [34] XANTHOPOULOS, Spyros and Stelios XINOGALOS. A comparative analysis of cross-platform development approaches for mobile applications. In: Proceedings of the 6th Balkan Conference in Informatics on - BCI '13. New York, NY, USA: ACM Press, 2013, pp. 213-220. ISBN 9781450318518. DOI: 10.1145/2490257.2490292. Available from: http://dl.acm.org/citation.cfm?doid=2490257.2490292 [35] PhoneGap [online]. © 2015, Adobe Systems, Inc. [cit. 20. April 2015]. Available from: http://phonegap.com/ [36] LEROUX, Brian. PhoneGap, Cordova, and what’s in a name?. In: PhoneGap Blog [online]. 19. March 2012 [cit. 20. April 2015]. Available from: http://phonegap.com/2012/03/19/phonegap-cordova- and-what's-in-a-name/ [37] Apache Cordova [online]. © 2015, The Apache Software Foundation [cit. 20. April 2015]. Available from: http://cordova.apache.org/ [38] Ionic: Advanced HTML5 Hybrid Mobile App Framework [online]. © 2013- 2015, Drifty Co [cit. 20. April 2015]. Available from: http://ionicframework.com/ [39] GRISOGONO, Grgur. 5 Best Mobile Web App Frameworks: Ionic (AngularJS). In: Modus Create [online]. 3. March 2014 [cit. 20. April 2015]. Available from: http://moduscreate.com/5-best- mobile-web-app-frameworks-ionic-angulalrjs/ [40] RAJ, Jay. The Top 7 Hybrid Mobile App Frameworks. In: Sitepoint [online]. 7. November 2014 [cit. 20. April 2015]. Available from: http://www.sitepoint.com/top-7-hybrid-mobile-app-frameworks/ [41] Create native iOS, Android, Mac and Windows apps in C# [online]. © 2015, Xamarin Inc. [cit. 20. April 2015]. Available from: http://xamarin.com/platform [42] Building Cross Platform Applications. In: Xamarin Guides [online]. © 2015, Xamarin Inc. [cit. 20. April 2015]. Available from: http://developer.xamarin.com/guides/cross- platform/application_fundamentals/building_cross_platform_applicati ons/ [43] Appcelerator Platform [online]. © 2008-2015, Appcelerator Inc. [cit. 20. April 2015]. Available from: http://www.appcelerator.com/product/

68 REFERENCES

[44] VANTOLL, TJ. How NativeScript Works. In: Telerik Developer Network [online]. 16. February 2015 [cit. 30. December 2015]. Available from: http://developer.telerik.com/featured/nativescript-works/ [45] Adobe AIR. In: adobe.com [online]. © 2015, Adobe Systems, Inc. [cit. 10. May 2015]. Available from: http://www.adobe.com/products/air.html [46] Swiffy. In: Google Developers [online]. © 2015, Google. Available from: https://developers.google.com/swiffy/ [47] Shumway [online]. © 2015, Mozilla [cit. 23. April 2015]. Available from: http://mozilla.github.io/shumway/ [48] YOGIN, Suhas. Creating and publishing an HTML5 Canvas document. In: Flash Professional Help [online]. 2015 [cit. 6. December 2015]. Available from: https://helpx.adobe.com/flash/using/creating- publishing-html5-canvas-document.html [49] ASOKAN, Subash. Converting your Flash Ads to HTML5 Canvas. In: Adobe Flash Professional Team Blog [online]. 14. July 2015 [cit. 6. December 2015]. Available from: http://blogs.adobe.com/flashpro/converting-your-flash-ads-to-- canvas/ [50] LEE, Rich. Welcome Adobe Animate CC, a new era for Flash Professional. In: Adobe Professional Team Blog [online]. 30. November 2015 [cit. 6. December 2015]. Available from: http://blogs.adobe.com/flashpro/welcome-adobe-animate-cc-a-new-era- for-flash-professional/ [51] BERNERS-LEE, Tim. Information Management: A Proposal. In: World Wide Web Consortium (W3C) [online]. 1989 [cit. 10. May 2015]. Available from: http://www.w3.org/History/1989/proposal.html [52] Can I Use...: Support for HTML5, CSS3, etc. [online]. © 2015 [cit. 7 May 2015]. Available from: http://caniuse.com/ [53] KUNC, Peter. Framework for Developing Offline HTML5 Applications [online]. Brno, 2013 [cit. 27. April 2015]. Available from: http://is.muni.cz/th/324997/fi_m/. Master thesis. Masaryk University. [54] GASSTON, Peter. The book of CSS3: a developer's guide to the future of web design. 2nd edition. San Francisco, CA: No Starch Press, 2015, xxii, 279 pages. ISBN 15-932-7580-3. [55] CSS3. In: Mozilla Developer Network [online]. © 2005-2015, Mozilla [cit. 4. May 2015]. Available from: https://developer.mozilla.org/en- US/docs/Web/CSS/CSS3

69 REFERENCES

[56] TIOBE Index [online]. © 2015, Tiobe Software [cit. 5. May 2015]. Available from: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [57] OSMANI, Addy. Learning JavaScript design patterns. Sebastopol, CA: O'Reilly Media, 2012, xii, 235 p. ISBN 14-493-3181-5. [58] ZAKAS, Nicholas C. Understanding ECMAScript 6 [online]. 2015 [cit. 5. May 2015]. Available from: https://leanpub.com/understandinges6 [59] HOBAN, Luke. Overview of ECMAScript 6 features [online]. 2015 [cit. 5. May 2015]. Available from: https://github.com/lukehoban/es6features [60] KATZ, Yehuda. Understanding JavaScript Function Invocation and "this". In: yehudakatz.com [online]. 11. August 2011 [cit. 5. December 2015]. Available from: http://yehudakatz.com/2011/08/11/understanding-javascript-function- invocation-and-this/ [61] KYLE, James. 6.0.0 Released. In: Babel Blog [online]. 29. October 2015 [cit. 5. December 2015]. Available from: http://babeljs.io/blog/2015/10/29/6.0.0/ [62] YOUNG, Alex R. JavaScript Developer Survey 2014: Results. In: DailyJS [online]. 16. December 2014 [cit. 6. May 2015]. Available from: http://dailyjs.com/2014/12/16/1333-javascript-survey-results/ [63] Front-end JavaScript frameworks. In: Explore GitHub [online]. 30. September 2014 [cit. 7. May 2015]. Available from: https://github.com/showcases/front-end-javascript-frameworks?s=stars [64] AngularJS: Superheroic JavaScript MVW Framework [online]. © 2015, Google [cit. 7. May 2015]. Available from: https://angularjs.org/ [65] SESHADRI, Shyam and Brad GREEN. AngularJS: Up and Running. Sebastopol, CA: O'Reilly Media, 2014. ISBN 1-4919-0194-2. [66] OSMANI, Addy. Developing Backbone.js Applications [online]. 2013, xvi, 354 pages [cit. 7. May 2015]. ISBN 1-4493-2824-5. Available from: http://addyosmani.github.io/backbone-fundamentals/ [67] Backbone.js [online]. 2014 [cit. 7. May 2015]. Available from: http://backbonejs.org/ [68] Karma: Spectacular Test Runner for Javascript [online]. 2015 [cit. 7. May 2015]. Available from: http://karma-runner.github.io/

70 REFERENCES

[69] LEE, Rich. Update about Edge Tools and Services. In: Adobe Edge Animate Team Blog [online]. 30. November 2015 [cit. 5. December 2015]. Available from: http://blogs.adobe.com/edge/2015/11/30/update-about- edge-tools-services/ [70] Flux: Application Architecture for Building User Interfaces [online]. © 2014- 2015, Facebook Inc. [cit. 29. November 2015]. Available from: https://facebook.github.io/flux/docs/overview.html [71] ZAKAS, Nicholas C. Enterprise JavaScript Error Handling. In: SlideShare [online]. 1. October 2008 [cit. 30. November 2015]. Available from: http://www.slideshare.net/nzakas/enterprise- javascript-error-handling-presentation

71

Appendix A: Screenshots of all the Alf Tasks

The following pages contain screenshots of all the types of tasks supported by Alf software and implemented in the new HTML5 application. It shows the variability of the UI and outlines the wide range of possibilities in the Alf tests. Each Alf task is also marked with its 3 letter abbreviation, which is used throughout the source code.

73 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

1 Single Choice (text) – VJO

Attachment 1: Screenshot of the Single Choice (text) Alf task with 5 options

74 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

2 Single Choice (pictures) – VJ2

Attachment 2: Screenshot of the Single Choice (pictures) Alf task with 4 pictures as options

75 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

3 Multi Choice (text) – VVO

Attachment 3: Screenshot of the Multi Choice (text) Alf task with 5 textual options

76 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

4 Multi Choice (pictures) – VV2

Attachment 4: Screenshot of the Multi Choice (pictures) Alf task with 4 pictures as options

77 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

5 Memory Game – PEX

Attachment 5: Screenshot of the Memory Game Alf task with 8 pairs

78 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

Attachment 6: Screenshot of the Memory Game Alf task evaluated – with the front side up

79 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

6 Category Sort – SKU

Attachment 7: Screenshot of the Category Sort Alf task with 3 categories and 8 options

80 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

7 Matching (text) – PRI

Attachment 8: Screenshot of the Matching (text) Alf task with 4 pairs

81 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

8 Matching (pictures) – PRO

Attachment 9: Screenshot of the Matching (pictures) Alf task with 4 pairs, enhanced with pictures and sounds

82 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

9 Order (vertically) – ZOR

Attachment 10: Screenshot of the Order (vertically) Alf task with 6 statements to order

83 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

10 Order (horizontally) – ZOP

Attachment 11: Screenshot of the Order (horizontally) Alf task with individual letters to order

84 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

11 Picture Labeling – POB

Attachment 12: Screenshot of the Picture Labeling Alf task with 6 labels

85 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

12 Flashcards – SNP

Attachment 13: Screenshot of the Flashcards Alf task with correctly submitted inequality button

86 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

13 Puzzle – PZZ

Attachment 14: Screenshot of the Puzzle Alf task with a picture divided into 5x3 pieces

87 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

14 Guess the Word (hangman) – SBN

Attachment 15: Screenshot of the Guess the Word (hangman) Alf task partly finished

88 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

15 Crossword – KRZ

Attachment 16: Screenshot of the Crossword Alf task with a question popup visible

89 APPENDIX A: SCREENSHOTS OF ALL THE ALF TASKS

16 Gap Filling – DOP

Attachment 17: Screenshot of the Gap Filling Alf task with some gaps filled in

90

Appendix B: Source Code

The thesis is accompanied with the source code of the new Alf HTML5 ap- plication. It includes a README file with the instructions on how to run the web application as well as a description of the structure of the source code.

91

Appendix C: Prototypes and Experiments

The thesis is also accompanied with several prototypes and experiments created during the development of the Alf HTML5 application. Some of them are mentioned in the thesis. The code may lack detailed documentation due to its experimental purpose.

93