Masaryk University Faculty of Informatics

Design of a web application for introductory programming

Bachelor’s Thesis

Adam Král

Brno, Spring 2020

Masaryk University Faculty of Informatics

Design of a web application for introductory programming

Bachelor’s Thesis

Adam Král

Brno, Spring 2020

This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Adam Král

Advisor: Mgr. Tomáš Effenberger

i

Acknowledgements

I could not have done this alone, and I would not have wanted to. My thanks belong to my advisor Tomáš Effenberger, for guiding my work and helping me evaluate my thoughts and ideas. I would also like to thank my parents, sister and other family members who supported me and created the right environment needed for me to focus. My thanks also belong to Anna, who repeatedly read this thesis, tested the application and provided me with valuable feedback. I am also grateful to all my friends who tried the system and gave me feedback. I would also like to express gratitude to Masaryk University, specifically Faculty of Informatics and its members for providing me with valuable knowledge and with a community I can belong to.

iii Abstract

This thesis presents the process behind creating a modern design of a web application, specifically web application for introductory programming. The thesis elaborates the choices in redesigning to implement latest technologies, meet demands created by new devices and support novel means of usage. The resulting design is then tested with automated test suites and human users for its usability and user experience.

iv Keywords

Web Application, JavaScript, HTML, CSS, Design, User Experience, UX, User Interface, UI, Introductory Programming

v

Contents

Introduction1

1 Overview3 1.1 Applications for introductory programming ...... 3 1.1.1 Block-based programming...... 3 1.2 Robomission ...... 3 1.3 Web Platform ...... 3 1.3.1 Responsive web applications...... 4 1.3.2 Progressive Web Applications...... 4 1.4 Design ...... 5 1.5 Material Design ...... 5

2 Design requirements7 2.1 Home page ...... 7 2.1.1 Loading speed...... 7 2.2 Space game ...... 7 2.3 Tasklist ...... 8 2.4 Responsiveness ...... 8

3 Design proposals 11 3.1 Setting theme ...... 11 3.1.1 Font...... 11 3.1.2 Colour theme...... 11 3.2 Home page ...... 13 3.3 Simulator ...... 13 3.4 Tasklist ...... 16 3.5 Animations ...... 17 3.5.1 Space game...... 17 3.5.2 Home page...... 20

4 Implementation 21 4.1 Application deployment using containerization ...... 21 4.2 Used frameworks and libraries ...... 22 4.2.1 React...... 22 4.2.2 Blockly...... 22 4.2.3 React Material-UI...... 23

vii 4.2.4 Updating versions of frameworks...... 23 4.3 Responsiveness ...... 24 4.4 Home page ...... 24 4.4.1 Login and registration...... 25 4.4.2 Loading time...... 25 4.5 Simulator ...... 26 4.5.1 Animations...... 27 4.6 Tasklist ...... 27 4.7 Making our application a Progressive Web Application ... 27 4.8 Using meta values for being shared and web-crawled .... 28

5 Testing 31 5.1 Using automated test suites ...... 31 5.2 Testing with real users ...... 31

6 Conclusion 33 6.1 Further work ideas ...... 33 6.1.1 Accessibility...... 33 6.1.2 Better PWA...... 34 6.1.3 Captivating story...... 34

Bibliography 35

A Attachments 37

B Preview of the redesigned application 39 B.1 Preview on a desktop computer ...... 39 B.2 Preview on a mobile phone ...... 39

viii List of Tables

ix

List of Figures

2.1 The space game 8 2.2 The look of the old home page on a mobile phone 9 3.1 Fonts used in our application 12 3.2 The prototype of home page 14 3.3 Different proposal of simulator layout on mobile devices 15 3.4 Paper wireframes of simulator 16 3.5 Final landscape wireframe of the simulator 17 3.6 Final portrait wireframe of the simulator 18 3.7 Old design (below) and new wireframe (above) of the tasklist 19 3.8 Possible approaches to rocket animation 20 4.1 The old look of the code simulator 28 4.2 Comparison of former and latter web-site linked with a thumbnail 29 B.1 The home page on computer display 40 B.2 The simulator on computer display 40 B.3 The tasklist on computer display 41 B.4 Installed PWA on a desktop computer with Ubuntu Linux 42 B.5 Installed PWA shortcut on a desktop computer with Ubuntu Linux 43 B.6 The simulator on a mobile phone display 44 B.7 The simulator on a mobile phone display 45 B.8 The tasklist on a mobile phone display 46 B.9 The simulator as a PWA in full-screen and landscape orientation on a mobile phone 47

xi

Introduction

Nowadays, web technologies are making progress faster than ever be- fore. As users move from desktop devices to mobile devices, desktop- first interfaces are becoming obsolete, and the increasing percentage of services is designed mobile-first. Besides this paradigm shift, the design of web applications is also advancing, as the visual design is responsible for the first impression on potential customer or user. A particular design is not something that is intended to stay - it changes with how we interact with the product. The process of creating a new design per se is, however, more permanent. We hereby describe the process of redesigning the application, specifically the web application Robomission. The description covers our discussions, design choices, implementation details, and reference points for future work. In the first chapter, we take a look at the useful terms and trends in web design. The second chapter sets out the resulting specific de- sign requirements of our application. Making of design proposals conforming to these requirements is described in the third chapter. The implementation of design proposals and individual components is examined in the fourth chapter. The fifth chapter is dedicated to test- ing our final design. Finally, the sixth chapter includes the evaluation of the product, the fulfilment of proposed plans and opportunities for future development.

1

1 Overview

1.1 Applications for introductory programming

Applications suited for teaching users to code are called Applications for introductory programming. They take various approaches to learn- ing. Application Robomission got its inspiration from Lightbot, Khan Academy, Hour of Code and Blockly Games [1, p. 3].

1.1.1 Block-based programming Programming languages that use commands in block form instead of writing code are called block-based. User can usually drag blocks to arrange them in the desired order for execution. Not every part of the syntax is in block form - some parts of syntax would be inconvenient to work with if they were in block form, such as numbers of repetitions of cycle. Block-based programming was selected thanks to its ease of comprehension. Further discussion about used approaches was done in work of Tomáš Effenberger [1, p. 3].

1.2 Robomission

Tomáš Effenberger created the application Robomission in 2018[1]. The application was focused rather on artificial intelligence possi- bilities than on a good design. Nevertheless, the design of a then- created application was a solid base for the design created in this thesis. Robomission is the application for learning introductory pro- gramming, particularly focused, but not limited to children. The pro- gramming language used for learning is block-based, as it has been shown that block-based programming languages lead to better com- prehension, entertainment, memory retention and are generally more suitable for learning to code [2].

1.3 Web Platform

Development of web applications has recently undergone a massive rise in popularity. The only requirement of running a web application

3 1. Overview is the browser and network connection, which makes this platform attractive - a large number of devices (mobile phones, laptops, tablets, even smart televisions) meets these requirements. Developer who needs to write a multi-platform application can design it for a browser and then delegate the integration of the application to developers of the browsers. As the web application runs in the browser, there is no need for installation or prior configuration. All the user has to do is to enter the URI address. Furthermore, the user does not have to be concerned with updates, as the update of the web application is done every time it is loaded. Nowadays, the majority of developers write code for web platform applications. Of all languages, JavaScript, HTML and CSS were the most used languages in 2018 [3].

1.3.1 Responsive web applications

The devices being able to connect to the Web are very different from the ages when the Web was invented. To access the Internet today, user can choose from a variety of devices running a variety of operating systems. Devices throughout this spectrum differ in parameters, such as display size, speed of connection, pixel density. Most of today responsiveness guides for developers target the display size, but the original definition was a lot wider. In the article mentioning the responsive design for the first time, the author writes: We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design [4]. Responsive design, therefore, means responding to all of the media properties, not only to the dimensions of the display.

1.3.2 Progressive Web Applications

The web platform functionality is still expanding, and it already started to compete with native applications. One way of creating an almost native experience from an application is by creating a Progressive web application (PWA).

4 1. Overview

PWAs are a type of application software delivered through the Web and built using standard web technologies including HTML, CSS and JavaScript. They are intended to work on any platform that uses a standards-compliant browser. Functionality includes working offline, push notifications, and device hardware access, enabling creating user experiences similar to native applications on desktop and mobile devices [5]. Recently, more and more web services are made as Progressive Web Applications (PWA), enabling web developers to create full-featured applications. The PWA can be almost indistinguishable from the native application (the less complex native applications can be fully repro- duced by PWA). The major advantage of PWA over native application is its size - as the PWA is built on top of the native browser code, its size is not much different to that of a corresponding web application. All these features are relevant for Robomission.

1.4 Design

Contrary to popular belief, designing an application does not consist exclusively of creating a pleasant look. Design is concerned with how things work, how they are controlled, and the nature of the interaction between people and technology [6, p. 5]. Therefore, the goal of good design is not only to make the product visually appealing, but also easy to comprehend, simple to control, and fun to play with.

1.5 Material Design

The majority of wide-used mobile applications today are made with Material Design. The Material Design was announced on Google con- ference in the year 2014. Since this event, Material Design has been steadily rising in popularity. Material is an adaptable system of guide- lines, components, and tools that support the best practices of user interface design. Backed by open-source code, Material streamlines col- laboration between designers and developers and helps teams quickly build beautiful products [7]. Material Design guidelines include el-

5 1. Overview ements used in UI, colour theme rules, animation rules, icons and much more1.

1. https://material.io/design

6 2 Design requirements

The first step in redesigning an application is defining goals andde- termining existing problems. We have decomposed the application into four independent application components: ∙ Home page ∙ Code visualizer (rocket flying through space), also called "space game" in this thesis ∙ Code editor - Blockly playground, also called "simulator" in this thesis, includes a space game ∙ Tasklist

2.1 Home page

The home page often determines the user’s decision to use or not to use the application. Our home page needs to be vivid, engaging and has to communicate the application’s purpose well. The content on our home page has to be easily comprehensible. Elements shown to the user immediately after arrival should have an obvious meaning. Our home page should also emphasize the fun behind learning to code via Robomission.

2.1.1 Loading speed The loading speed of the home page is one of the most significant aspects in determining if the user stays on the page. It was found that sites loading within 5 seconds had 70% longer sessions, 35% lower bounce rates, and 25% higher ad viewability than sites taking nearly four times longer at 19 seconds [8]. As the home page is the most probable landing page for new users, the faster we load it, the less likely the potential user is to leave our application.

2.2 Space game

The evaluation of the user’s code blocks takes place in the space game, which serves as primary feedback to the user. It provides visual cues of the code progress. User can figure her task fulfilment via the graphical

7 2. Design requirements

Figure 2.1: The space game output (figure 2.1), where a rocket flies through the universe and collects collectables, or dodges and shoot meteorites. The space game needs to communicate the task fulfilment or failure and its reason. The space game also needs to convey the connection between events in it (rocket hit the rock) and commands in the code editor (move rocket left).

2.3 Tasklist

The tasklist serves as the overview of progress in Robomission. User can also use it to get back to favourite tasks and replay them.

2.4 Responsiveness

Many versions of different browsers commonly use web services. At the time of writing, mobile devices share 45.91% of web usage, making them an equivalent opponent for desktop devices (50.23%) [9]. Design of a web application today, therefore, needs to be mobile-friendly more than ever before. The old design of Robomission’s home page (figure 2.2) was re- sponsive but was not displaying correctly on mobile devices(with less than 6 inches big display). In mobile browsers, the navigation bar and the status bar is taking significant space on the screen. As we need to utilize all the available space on display, we provide the user with a full-screen option in

8 2. Design requirements

Figure 2.2: The look of the old home page on a mobile phone

9 2. Design requirements our navigation bar. The application Robomission is SPA (Single Page application), so it is sufficient to activate full-screen only once (for the entire user visit of the site). The full-screen option also offers the user a more game-like experience.

10 3 Design proposals

We assessed the design requirements to create design proposals for parts of the site to be redesigned. We have created wireframes, which served later as a rough estimate of design, shape and functionality of a user interface. We used them as guidelines while rewriting the application design.

3.1 Setting theme

Our theme needed to adapt itself to its audience base. Our audience base is composed mostly of children - we need our theme to be colour- ful, energetic, playful and even childish.

3.1.1 Font A properly chosen font can help application convey its meaning. It can also help application establish its visual identity. We selected our font from Google fonts library1. All fonts in this library are open source and hosted by Google so that we can rely on Google serving our selection properly and in time. We needed a font that is as playful as our design, maybe even a little childish and futuristic (to fit our story setup). For titles, we chose Righteous2. For body text, we chose Roboto3 for its legibility - children that are still learning to read will appreciate high legibility. Roboto is also frequently used, raising the probability of being already cached from another site that the user has visited before. These fonts can be seen in figure 3.1, along with different weights we have used.

3.1.2 Colour theme The colour theme was already chosen in the previous design. General rules for selecting the colour theme is not to choose too many colours. We violated this rule, justifying it with the fact that children enjoy

1. https://fonts.google.com/about 2. https://fonts.google.com/specimen/Righteous 3. https://fonts.google.com/specimen/Open+Sans

11 3. Design proposals

Figure 3.1: Fonts used in our application

12 3. Design proposals plenty of colours, and particularly, the vivid ones. We used colours from Material UI guidelines, specifically cyan and amber. The ele- ments in our game are not limited to these theme colours, as it would be in generic application. The background is black, resembling the look of the space. The text is white and sometimes in shades of grey, sufficiently light to preserve high contrast ratios for readability.

3.2 Home page

We adjusted the home page to communicate its purpose more eas- ily by changing the visual weight of essential elements. The home page had been previously designed by using full-screen subsections telling simple and clear ideas (these subsections are called "slides" in our application). The navigation is done by scrolling or pressing the bright, prominent button with an arrow pointing down. By pressing it, browser scrolls to the next slide. The most notable change we made is making the typography bigger (and also simulator), allowing better readability and interaction on mobile devices. We also made sure that there are no unnecessary elements shown to the arriving user. The resulting wireframe can be seen in figure 3.2, with different types of the buttons under the space game to visually compare them.

3.3 Simulator

The layout of the simulator needed more work because of the require- ment to support mobile devices. Their smaller screens was a bit more challenging, as all of the information displayed must be on the same viewport (unlike the home page, where the information can be di- vided into multiple viewports. or so-named slides). We have made more than one layout proposals and discussed the advantages and disadvantages of them (figure 3.3). There are not all elements of the application, as we needed only the rough sketch of the most signifi- cant elements for latter discussion about layouts of other necessary elements on this sketch. After this initial examination, we created paper models of compo- nents seen in figure 3.4. These models were the same constraints as the corresponding element on web site on the phone which display was

13 3. Design proposals

Figure 3.2: The prototype of home page

14 3. Design proposals

Figure 3.3: Different proposal of simulator layout on mobile devices

15 3. Design proposals

Figure 3.4: Paper wireframes of simulator

the same dimensions as the smallest displays we aimed to support (4.6 inches diagonal length, 5.73 centimetres wide, 10.18 centimetres high). Resulting paper wireframes were then tested for their "look and feel", ensuring that all elements have sufficient spacing and are big enough. Finally, we selected and digitalized the most suitable wireframe configurations - one for landscape (figure 3.5) and one for portrait (figure 3.6).

3.4 Tasklist

We reused the form of previous tasklist design. The only changes we made were to suit the futuristic theme better. The difference between the old design and proposed wireframe can be seen in figure 3.7.

16 3. Design proposals

Figure 3.5: Final landscape wireframe of the simulator

3.5 Animations

Animating an object on display makes the object more natural, as the real-world objects are seldom moving discretely from one position to another. Children are also captivated by animations, following them and giving attention to them, what is appropriate for our application.

3.5.1 Space game The rocket in the space game can perform instructions for movement in 3 different manners of animation: ∙ It just appears in the next position. ∙ Movement is smoothed over the entire program run. ∙ Movement is smoothed only over the individual commands. First creates a jerky and raw impression. The second option looks seamless, but it does not emphasize individual steps of source code. Last option is ’best of both worlds’, making a pleasant transition be- tween positions, but also stopping between steps, so two different commands are executed as two different moves. The graph of anima- tion progress through time is available on figure 3.8.

17 3. Design proposals

Figure 3.6: Final portrait wireframe of the simulator

18 3. Design proposals

Figure 3.7: Old design (below) and new wireframe (above) of the tasklist

19 3. Design proposals

2 A B C 1.5

1

0.5 position of animated object 0

0 0.5 1 1.5 2 time Figure 3.8: Possible approaches to rocket animation

3.5.2 Home page The home page has to include many animated elements to create an interactive and playful feel. We settled on animating at least the background sky, the rocket in the foreground and the previously mentioned space game, which is also present on the home page.

20 4 Implementation

The screenshots of components implemented with new design can be seen in appendixB.

4.1 Application deployment using containerization

The original application was developed as a Python application with the Django framework and a virtual environment. We redesigned the application deployment using Docker. Docker is a tool designed to make it easier to create, deploy, and run applications by using containers1. The advantages of containerization are ∙ Consistent deployment - as long as the target machine has Docker, it is sufficient to run Docker command to build and then to start the service. ∙ Added security - by containing the application in its virtual container with virtual resources, we mitigate the risk of security flaws as we can exactly determine which resources are shared between the host machine and the container. ∙ Higher uptime - Resetting the application which has only one instance suffers from being offline while the application isstart- ing up, but still unable to process request. Docker solves this by spawning a new instance of the application and then switching to it only when it is ready to accept connections. We wanted to develop the application on multiple machines. However, it did not deploy itself consistently, so we decided to use Docker to solve inconsistencies between different configurations and environ- ments of our machines. Later in development, we used this container- ized version together with Docker Compose2 and Ansible3 to deploy the development version of Robomission on a server with domain to test and share it in the development phase. Although those technolo- gies are not mandatory for deploying an application, they simplified it significantly by automatizing tasks needed for deployment and uni-

1. https://opensource.com/resources/what-docker 2. https://github.com/docker/compose 3. https://github.com/ansible/ansible

21 4. Implementation fied differences in environments created by different host machines and their setups.

4.2 Used frameworks and libraries

The most of decisions in code style and Robomission implementation can be attributed to React, Blockly and React Material-UI libraries (apart from libraries that these libraries use). The full list of technolo- gies used is attached as an appendix in work of Tomáš Effenberger [1, p. 61]. In addition to these, we used Docker, Docker Compose and Ansible mentioned in the previous section.

4.2.1 React React4 is a JavaScript library for building web applications. Core fea- tures of React are ∙ Components - React code is made of entities called compo- nents. Components let developer split the UI into independent, reusable pieces, and think about each piece in isolation5. ∙ Immutable states of the application, and using state changes for deciding when to rerender a component. ∙ JSX - Syntax extension to JavaScript. With JSX, it is possible to couple HTML, CSS and JS for one component in one JSX file. ∙ Virtual DOM - React creates an in-memory data-structure cache, computes the resulting differences, and then updates the browser’s displayed DOM efficiently6. We decided to keep React from the previous implementation as it is still properly maintained at the time of writing.

4.2.2 Blockly Google’s Blockly7 is a web-based, visual programming editor. Users can drag blocks together to build programs. All code is free and open-

4. https://reactjs.org/ 5. https://reactjs.org/docs/components-and-props.html 6. https://reactjs.org/docs/refs-and-the-dom.html 7. https://github.com/google/blockly

22 4. Implementation

source. Many applications for introductory programming use it, and at the time of writing, it is still well maintained.

4.2.3 React Material-UI React Material-UI is design component library conforming Google Material Design specification8. Material Design is considered modern at the time of writing, but design trends are quickly changing. We even diverged a bit of the Material Design to create a more modern look and to make Robomission distinguishable between other sites using Material Design.

4.2.4 Updating versions of frameworks The Robomission app was originally written in 2018. Since then, new major versions of frameworks used in Robomission has been released. Keeping used technologies up to date has many advantages, including ∙ Security fixes ∙ Bug fixes ∙ New features - new React 169 features are fragments, error boundaries, portals, support for custom DOM attributes and improved server-side rendering. ∙ Better product - The React 16 is smaller, compared to React 15.6.1. Since the initial Robomission development, Material-UI has re- leased 4 major versions and React has released 1 major version. These updates introduced breaking changes (without backwards compat- ibility). When a company (or a team) releases new version of their product, it is generally expected to release a migrating manual with it. We used numerous migrating manuals, notably: ∙ Upgrading React from 15.6 to 16.0 ∙ React.Component and its lifecycle ∙ Upgrade guide React-intl from v1.x to v2.x ∙ Material UI migration From v0.x to v1 ∙ Material UI migration from v3 to v4

8. https://material.io/design/ 9. https://reactjs.org/blog/2017/09/26/react-v16.0.html

23 4. Implementation 4.3 Responsiveness

The frameworks used for creating responsive sites usually take the dimensions of the device and then assign them a category which will then be used in determining the constraints of the layout. These categories are called breakpoints - Material UI for React uses 5 of them (named xs, sm, md, lg and xl)10. The responsiveness of an application using Material-UI library is implemented by using designated Material-UI Grid components. The developer only specifies sizes of these Grids serving as a container for inner elements. The sizes are specified separately for different breakpoints. Responsive typography was introduced in version 4 of Material-UI. We took advantage of this feature, making text scale on smaller devices to fit the screen width. We have also made sure that all elements of the page are visible on most frequent device desktop dimensions - several companies publish these statistics annually or monthly, notably StatsCounter11 and w3schools12.

4.4 Home page

The previous implementation was heavily using hacks for positioning (specifically, centring) elements. We could avoid this with flexboxes, which are intended to make positioning easy and predictable on every supported browser. We redesigned the home page using the Grid components internally using flexbox. We used the underlying flexbox properties further to tweak some of the properties of the resulting layout. The main drawbacks of using the Grid component of React in comparison to other responsive layout frameworks for us were ∙ Not able to specify grid offset. ∙ Not able to specify grid elements that will not be visible in some sizes. These drawbacks were easily mitigated by using the native CSS properties (flex-basis for the offset and display for visibility).

10. https://material-ui.com/customization/breakpoints/ 11. https://gs.statcounter.com/screen-resolution-stats 12. https://www.w3schools.com/browsers/browsers_display.asp

24 4. Implementation

We also implemented new animations mentioned in chapter3.

4.4.1 Login and registration The user will not probably complete our application in one session. She can use registration and login buttons to save her progress to her account and then load it when needed. For registration login, we used the Dialog component. The Dialogs are purposefully interruptive, so they should be used sparingly13 - as the login is done only once per entire user session, we decided that it is adequate to use Dialog component. The Google and Facebook logins were only accessible through the login Dialog. This could make user register with name and password, unaware of taking advantage of Google and Facebook login (which are significantly more comfortable to carry out, making a better and more seamless user experience). Taking this into account, we reorganized Dialogs for registering and logging in.

4.4.2 Loading time Using Google Lighthouse speed test14, the original page took 8 seconds to load. Google Lighthouse evaluated that as "slow", so there was room for improvement. We do not want to endorse Google Lighthouse speed test as an objective mean of measuring site performance - we did use it only as an indication of improvement of page loading speed of a major web browser at the time of writing. Initially, the home page had been loading 1 MB of bundled JavaScript files (1 MB after compression, 5 MB before). This isnot optimal, as it is possible to split the code into more chunks and load only the necessary bits for the home page to be shown to the user. Other parts of the code can be loaded later. React framework offers this functionality (called ’code-splitting’) out-of-the-box with Suspense component and React.lazy functionality15. Home page image was formerly 1.5 MB large PNG file. As it is not photography, but sketched drawing, the SVG file format is more

13. https://material-ui.com/components/dialogs/ 14. https://developers.google.com/web/tools/lighthouse 15. https://reactjs.org/docs/code-splitting.html

25 4. Implementation suitable than the PNG. We vectorized the home page image, as it is needed for the first render of the home page. After vectorizing, images used in initial render were only about 20 KB in total.

4.5 Simulator

Design of the simulator needs to be playful and vivid to be entertaining for the young user base, yet not too distracting for its counterpart. The former design was suitable enough; we just needed to make some tweaks to make it responsible. We needed to design simulator and playground screen so small that it will fit on the user’s screen while making sure that everyes- sential component will be visible on the user’s screen. The smallest we considered is 360x640 resolution seen commonly in small mobile devices. This resolution presented us with two challenges: 360x640, but also 640x360. The Top bar of Robomission also cannot fit small screens - we decided to not show every element on smaller screens for it to fit. We also needed to make sure our application is usable with touch input - tests showed that when children were given tasks to carry out a task, they preferred to use touch input and it was more natural to do so as using the mouse[10]. At the time of our work, the touch already became the primary way of interacting with web applications. Most of the tools and libraries we used were already working with the touch interface, so we needed to do only minor tweaks and make sure that the elements used in touch interactions are big enough to create a pleasant user experience. The old design was implemented via HTML tables. We used the SVG elements for the new implementation, as it allows to animate elements, apply styles and scale better. The original implementation computed element sizes with JavaScript for every element. As we rewrote the table to SVG, we specified sizes of elements in SVG in percents - that allowed us to delegate computing sizes of elements from our code to the browser’s rendering engine. It also allows more effortless adding and scaling of elements inthe future.

26 4. Implementation

We decided not to change the style of the Blockly playground, as it is widely used in block-based programming applications. We want to preserve the sense of familiarity in the case that the user has already used an application implementing Blockly library.

4.5.1 Animations The original implementation of the space game component is not ani- mated. Objects are created again for every animation frame, so merely changing CSS transitions did not work (the object is created and then placed, and CSS transition did animate this placement). We needed to add different animations to different elements and different frames. The CSS keyframes were most suitable for this kind of animation, as we can specify specific animation for each object in the space game.

4.6 Tasklist

We have also redesigned the tasklist to fit the futuristic theme of our design better. The floating stars were added to background as in the home page, so the black background will not look too void.

4.7 Making our application a Progressive Web Application

Transforming Robomission to a Progressive Web Application was done almost effortlessly, as the React framework supports PWA func- tionality out-of-the-box. The developer only needs to enable it by using appropriate function16. The features we planned for our PWA to have are ∙ Offline task solving ∙ Creating a home shortcut separate from the browser via the A2HS17 ∙ Running in full-screen by default

16. https://create-react-app.dev/docs/making-a-progressive-web-app/ 17. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_ apps/Add_to_home_screen

27 4. Implementation

Figure 4.1: The old look of the code simulator

To enable these features, the developer needs to write the manifest file with a declaration of rules needed for the browser to acknowl- edge. The application also needs to be served with HTTPS protocol. We managed to implement running in full-screen by default, offline functionality and A2HS. The offline functionality is very restricted, as the next task for the user is determined by the server recommendation algorithm. The resulting full-screen PWA application is on figure 4.1

4.8 Using meta values for being shared and web-crawled

Every website needs a way how it can manifest its meaning and content to various crawlers and search engines. Despite the primary purpose of giving information to the human user, we need to ensure that our home page can communicate that information also programmatically to crawlers and search engines. This is a common practice among developers of websites, known as Search Engines Optimization - SEO18 (although SEO is an umbrella term and includes more techniques). One way of describing site purpose and content for web crawlers is using tags in . Although some of the tags are used by browsers, standardized and universal (such as content type or lan- guage), some of them depend on specification solely from a company that owns the product used to share, and thus to crawl and index Robomise. These specifications are subject to change with every new technology or way to share web content.

18. https://en.wikipedia.org/wiki/Search_engine_optimization

28 4. Implementation

Figure 4.2: Comparison of former and latter web-site linked with a thumbnail

This is also needed, as our page is built with React and without Javascript being able to execute, there is almost no content for crawlers and search engines to scrape. After adequately using meta tags, social network platforms started to index them, and consequently, the sharing of Robomission changed in appearance, as seen in figure 4.2. The first two messages are the link to the previous version of Robomission and automatically attached thumbnail. The second two messages are link and thumbnail to the developed version.

29

5 Testing

Our testing approach was heavily influenced by one of the critically acclaimed books in the field: Don’t Make Me Think by Steve Krug. He describes, inter alia, a way to effortlessly test website during develop- ment and how it should be presented to testers - "If you want a great site, you’ve got to test. After you’ve worked on a site for even a few weeks, you can’t see it freshly anymore. You know too much. The only way to find out if it really works is to watch other people try touse it."[11, p. 111]

5.1 Using automated test suites

Google Lighthouse1 offers also tests targetting other metrics than per- formance. The other available metrics are accessibility, best practices and SEO. We implemented all of the suggestions made by this test suite, resulting in higher scores in every category. We also used GTMetrix2 to measure Robomission performance and find out more about suggestions by this test suite. The suggestions should not be blindly followed, as not all of them apply to every website.

5.2 Testing with real users

Testing of Robomission was performed by performing usability tests - Usability tests are about watching one person at a time try to use something (whether it’s a Web site, a prototype, or some sketches of a new design) to do typical tasks so you can detect and fix the things that confuse or frustrate them[11, p. 110]. The testing with real users was done iteratively throughout the entire development process, incorporating new findings as soon as possible. Notable changes from testing with users were

1. https://developers.google.com/web/tools/lighthouse 2. https://gtmetrix.com/

31 5. Testing

∙ Adding a diagonal arrow to the left and right instructions. Users thought that left and right would move their spaceship to the left or right, not diagonally (one field up and one field left/right). ∙ Adding ability to zoom the Blockly playground. Some users prefer to zoom in and out the playground while playing the Robomission. ∙ Making the joyride (hints that are shown when the user presses the small question mark in the top bar) more noticeable by adding a subtle animation to its icon. Merely changing the icon to amber was not sufficient to catch the user’s attention.

32 6 Conclusion

We have successfully implemented our new design, and we have made Robomission responsive (including usability on touch devices). We have also created an almost native experience with PWA implemen- tation and prepared ground for offline functionality. By testing our design with real users, we were able to pinpoint its weaknesses and fix them. The visual design we created will probably not survive the next wave of design trends. However, we hope that the process of creating a design we described will help designers with creating their own - even when our visual design will fall obsolete.

6.1 Further work ideas

6.1.1 Accessibility Although we did make some steps needed to make our application accessible for some of the people with disabilities, we did not test it thoroughly and with all relevant disabilities in mind. To make our application accessible, we ensured that these rules are respected: ∙ The contrast ratio of text and its background is high enough ∙ All essential elements of the application have its alternative description ∙ All input elements have its labels ∙ The application is controllable only with touch screen or only with keyboard ∙ All text and button elements are big enough - or if they are not, they can be zoomed We used Firefox accessibility explorer to mitigate accessibility is- sues, but this covered only the most basic and automatically detected problems. The accessible application has to conform to many stan- dards and rules - there is a diverse range of devices designed to help people access the Web. To ensure that all accessibility issues were acknowledged, we rec- ommend using official guidelines on accessibility from World Wide Web Consortium, such as Web Content Accessibility Guidelines 2.11.

1. https://www.w3.org/TR/2018/REC-WCAG21-20180605/ 33 6. Conclusion

Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Follow- ing these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address the accessibility of web content on desktops, laptops, tablets, and mobile devices. [12]

6.1.2 Better PWA Robomission PWA works nicely on devices supporting it, but there is much space for improvement. We could improve animations, notify the user to come back for learning when new tasks are added or make the layout of application look more like native applications.

6.1.3 Captivating story By now, the game is taking place in space and it has its theme, but we could create an engaging story for the user with plot and setting the missions to it.

34 Bibliography

1. EFFENBERGER, Tomáš. Adaptive System for Learning Programming [on- line]. 2018 [cit. 2019-11-15]. Available also from: https://is.muni. cz / th / p2dob/. Master’s Thesis. Masaryk University, Faculty of Informatics, Brno. Supervised by Radek PELÁNEK. 2. Comparing Block-Based and Text-Based Programming in High School Com- puter Science Classrooms [online]. David Weintrop, Uri Wilensky [vis- ited on 2019-07-02]. Available from: https://ccl.northwestern. edu/2017/a3_weintrop_wilensky.pdf. 3. Stack Overflow Developer Survey Results 2018 [online]. Stack Over- flow [visited on 2019-06-26]. Available from: https://insights. stackoverflow.com/survey/2018/#technology. 4. MARCOTTE, Ethan; FAST, Karl; ANDERSON, Stephen P.; KALBACH, Jim; SO, Preston; METTS, Michael J.; WELFLE, Andy. Responsive Web Design. 2010. Available also from: https://alistapart.com/ article/responsive-web-design/. 5. Progressive Web Apps [online]. Google [visited on 2020-02-08]. Available from: https://developers.google.com/web/progressive-web- apps. 6. NORMAN, Don. The Design of Everyday Things: Revised and Expanded Edition. Basic Books, 2013. ISBN 978-0-465-05065-9. 7. Material Design [online]. Google [visited on 2020-02-08]. Available from: https://material.io/. 8. Why Performance Matters [online]. Jeremy Wagner [visited on 2019-06-24]. Available from: https://developers.google.com/web/fundamentals/ performance/why-performance-matters/. 9. Desktop vs Mobile vs Tablet Market Share Worldwide [online]. Statcounter [visited on 2019-03-27]. Available from: http://gs.statcounter. com/platform-market-share/desktop-mobile-tablet.

35 BIBLIOGRAPHY

10. LU, Chengdong; FRYE, Douglas. Mastering the machine: A compari- son of the mouse and touch screen for children’s use of computers. In: TOMEK, Ivan (ed.). Computer Assisted Learning. Berlin, Heidel- berg: Springer Berlin Heidelberg, 1992, pp. 417–427. ISBN 978-3-540- 47221-6. 11. KRUG, Steve. Don’t make me think, revisited : a common sense approach to Web usability. San Francisco, California: New Riders, Peachpit, Pearson Education, 2014. ISBN 9780321965516. 12. COOPER, Michael; CONNOR, Joshue O; CAMPBELL, Alastair; KIRK- PATRICK, Andrew. Web Content Accessibility Guidelines (WCAG) 2.1. 2018. W3C Recommendation. W3C. https://www.w3.org/TR/2018/REC- WCAG21-20180605/.

36 A Attachments

Snapshot of the source code of the application is available as an attach- ment code.zip in the Archive of Thesis in the Information System of Masaryk University. It is also available in the GitHub repository of the project at https://github.com/N4M3L355/robomission.

37

B Preview of the redesigned application

These previews should not be considered as an exhaustive list of devices we tried to test our application. We selected only a few repre- sentatives to demonstrate the responsiveness and visual appearance of the redesign.

B.1 Preview on a desktop computer

The computer’s display is 1920×1200 pixels large. The operating sys- tem is Linux (Ubuntu 20.04) and browser used for screenshots B.1, B.2, B.3 is Firefox 76.0.1 (we compared the results with Chrome browser and fixed the inconsistencies). For the screenshots B.4 and B.5, we used Chrome browser, ver- sion 81.0.4044.129 on the same Ubuntu to install the PWA version of Robomission.

B.2 Preview on a mobile phone

We used a mobile phone for screenshots B.6, B.7, B.8, B.9. The phone used is Sony Xperia XZ1 Compact, with 360×640 viewport, 720×1280 pixels, 4.6 inches diagonally, 5.73×10.18 centimetres. Operating system is Android 9. Browser used is Chrome 81.0.4044.138.

39 B. Preview of the redesigned application

Figure B.1: The home page on computer display

Figure B.2: The simulator on computer display

40 B. Preview of the redesigned application

Figure B.3: The tasklist on computer display

41 B. Preview of the redesigned application

Figure B.4: Installed PWA on a desktop computer with Ubuntu Linux

42 B. Preview of the redesigned application

Figure B.5: Installed PWA shortcut on a desktop computer with Ubuntu Linux

43 B. Preview of the redesigned application

Figure B.6: The simulator on a mobile phone display

44 B. Preview of the redesigned application

Figure B.7: The simulator on a mobile phone display

45 B. Preview of the redesigned application

Figure B.8: The tasklist on a mobile phone display

46 B. Preview of the redesigned application

Figure B.9: The simulator as a PWA in full-screen and landscape ori- entation on a mobile phone

47