%\documentclass[10pt,a4paper]{article}
%\usepackage[utf8]{inputenc}
%\usepackage{amsmath}
%\usepackage{amsfonts}
%\usepackage{amssymb}
%\usepackage{listings}
%\usepackage{graphicx}
%\author{Richard Torenvliet - 6138861}
%\title{Flood Simulation Browser}
%\maketitle
\section{Introduction}
This project concerns the Flood Simulation Browser. The concept of this browser is to illustrate/visualize a flood in a particular area. With this technology people can see the flow that the water will take. When a dike breaks it is important to know where the water will flow. Information about which locations in the area will be under water first can result in a successful evacuation plan. This system already exists, but is build for a multi-touch table only and is accessible by few people. This project aims on making it easier available and accessible. Which makes it more likely that someone with the right authority can take decisions about placing/reinforcing dikes or creating evacuation plans. Moreover, if this system is more accessible, then civilians of a certain neighbourhood that is threatened by water, have the ability to take gain knowledge of where the water will go first. They then are able to take the the right crucial decisions based on this knowledge in hour of need.
The implementation will be on a multi-touch device. In particular iPad and Android tablets. Users can use this application in an intuitive way and get more intelligence about the complex situation at hand. They have the ability to choose from several simulations that were already made for a specific area and also creating new simulations.
This document covers design choices/options in order to reach that goal. The first step is to get an idea of the existing simulation system of which this application will take use of. This includes a clarification of where this application is situated in the Urban Flood Project as a whole. The next step will be finding out the requirements of the tablet implementation, like which features does it have to contain in order to maintain intuitiveness. Just by showing the data would not be sufficient. The function of this App is to extend the simulation system with a use-ability factor.
A side assignment of this project is testing the scalability of the REST server. By testing how much requests the server can handle at ones it helps the urban flood project to estimate how many users can use the application at ones. The original multi touch application on the multi touch table was only one client. It's important to know that an early warning system stays online under the pressure more of clients.

The scientific research of this project will be the research for an intuitive design. The question will be, where do buttons, lists, and other important components need to be situated in an application. An other aspect of this project is the research for scalability of the server. This data will provide information about how many users can be handled by a server at once will be the question. The last subject of this research will be the decision of which framework or tool to use for the implementation of this application.

\section{Flood Simulation System}
The simulation system already exists and runs in the Cloud. That means it does all the calculation for the client and it's not important to know at which physical computer it runs. The system can calculate simulations by providing parameters about a certain area. For instance, the location and how much water you want to simulate. When a simulation is submitted and calculated, the simulation is stored. With calls the system it returns a set of simulations that are present. The important thing to note is that the simulation consists of images that have to be displayed on a map, let's say Google Maps. The flood simulation system performs a complex simulation with the height map of the area. The height map holds detailed information about the height of an area. With this data, the flow of the water can be calculated and turned in to images. These images are used by the client application, this an important part of this project.
Not only does the system calculates the flow of water but it also calculates the estimated route that people take. It can calculate how much people would survive a simulated flood, keeping in mind that this project is all about saving people, this is interesting information.
 
\subsection{Flood API}
The API is a REST api that return JSON formatted string. It's a client server system where requests are done by the client and the appropriate data is transferred back to the client. With this data, information about a certain simulation can be displayed. The data can be in the form of an image or information in .csv files. The .csv files can be plotted and displayed in as a chart or graph.

\subsection{Scalability}
A side assignment of the project is to test the scalability of the server. The server address is \url{sangkil.science.uva.nl}. To test this server it is needed to exclude any other parameter of the client. Such as maximum download speed, maximum throughput, latency of the network. The idea is not to test this at a home pc, but test it in a server that is hooked up in the same network as sangkil.science.uva.nl. If this is the case the exclusion of restricted variables at client side could be possible. 
For stress testing the server a tool called siege \cite{Siege} would be of assistance. With this tool it is possible to launch requests to a url with $n$-nodes and $k$-connections executed per second. Siege registers the following data:
\begin{itemize}
\item Transactions - total hits
\item Availability - percentage of total succeeded hits
\item Elapsed Time - seconds
\item Data Transferred - MB
\item Response Time - seconds
\item Transaction Rate - seconds 
\item Throughput - MB/s
\item Concurrency - rate of concurrency
\item Succesful transaction - number of succeeded hits
\item Failed transactions - number of failed hits
\item Longest transaction - seconds
\item Shortest transaction - seconds
\end{itemize}
With this data new insight can be provided. By increasing the number of simultaneous connections, values could start to change. To really give the server a stress test, it's possible to provide a list of urls which can randomly be picked and executed. This simulates a more likely scenario and provides more insight on how the server would behave in a real situation. The expectation is that the response time might grow as the number of clients starts to grow. With more clients to serve, it could take longer if there are more clients active. If processor power is limited, maximum available memory is reached or even the implementation of the server for handling requests could all have an effect in the response time, or any other variable. The research for which variables changes, together with the cause and the solution is a part of this project and will be documented in the end report. 

\section{Flood Simulation App}
\subsection{Platform considerations}
As stated in the introduction the app is meant for tablets, but not specific for iOS or Android. How to maintain this demand on the application is one of the subjects of this project. This means that the application is not a native implementation and consists of one code-base and runs on more devices. There is a tool called PhoneGap  \cite{PhoneGap} that uses HTML5, CSS3 and Javascript to build the app. In essence the developer builds a mobile website and PhoneGap can wrap this in an application. The native web-engine is used to render the mobile website. PhoneGap can result in a huge speed-up in development time, which is a huge advantage.  The speed up can be obtained by the fact that previously gained skills of webdevelopment can be re-used. Therefore there is no need to learn a new programming language or sdk for native apps. For example Objective C for iOS and Java for Android. The disadvantage can be that it feels like a mobile website in stead of a native application. In addition, the end product depends on the support of today's web-standards. Not all browsers have full support for HTML5 and CSS3, which forms the bases of a successful implementation of the application. For a list of supported elements, websites like caniuse.com \cite{CSS3} can be used to determine the percentage of support for a certain element/feature. But does not solve anything. Nevertheless, one disadvantage can be solved, a native feel of an application. For example, frameworks where native-like elements are created for you while coding in a programming language already known by a webdeveloper also exists.

This solution is Titanium Mobile, the Appcelerator \cite{Titanium-Appcelerator}. Titanium Mobile can build mobile applications that are in fact native applications. By programming in Javascript and call functions to create native elements the application can be created. The framework builds semi-native code, in the contrary to previously discussed PhoneGap. The development for this platform is fast and an application for both iOS and Android are quickly of the ground. But there is also a disadvantage by using Titanium. The applications are big, around 11MB no matter what. Because of the fact that the logic will still be in javascript(compiled), Titanium has to ship their javascript engine to the device. But not only do they take a lot of space on the storage device, it also has trouble with memory, see this blog-post\cite{memoryleak}. The blog-post discusses this issue, both developers and users discuss this issue in the reactions. Although this blog post refers to version 1.6 and 2.0 is already out, it's a threat to this project that can pop-up unexpectedly.

Moreover developing and testing on iOS provides expected behaviour and a large part of native elements are supported, for Android the native elements are mostly \textbf{not} the elements you thought they would looked like. To reach cross-platform apps the developer needs to constantly keep track if they're building an element for iOS or for Android. It might be stated that the functionalities of different platforms are not evenly supported. iOS is far out the most supported platform. Which only provides an advantage if the project only meant to run for iOS. The idea of Titanium Mobile is great, it works fine but will delay developing time when you truly want to reach crossplatform.

\subsubsection*{Javascipt frameworks}
As already explained, PhoneGap only provides the possibility to create an app out of a website. This website can be build in any way the developer likes, using web technologies supported on the native device. There are frameworks that can speed up the development to make an intuitive application. Two frameworks that are considered are: jQuery Mobile \cite{jQuery-Mobile} and  Sencha Touch \cite{sencha}. 
\begin{description}
\item [jQuery Mobile]
This Javascript framework is build out of one Javascript file and one CSS file that the developer includes. By giving certain HTML elements a data attribute, which is a HTML5 element, the framework uses this to create views. A page is made by declaring a div adding data-role="page". Such a page can be given a footer like div data-role="footer". 
Switching frame one page to the other can be as simple as giving a html anchor a href to an id of a page. The figure \ref{fig:jquery} provides an example that will result in two pages, both pages have a button. Both buttons link to the other page (foo, bar), so tapping on one button will change the page to the other page.
\begin{figure}
\begin{lstlisting}
<div data-role="page" id='bar'>
	<a #href='foo' data-role="button">switch to foo</a>
</div>
<div data-role='page' id='foo'>
	<a #href='bar' data-role="button">switch to bar</a>
</div>
\end{lstlisting}
\caption{jQuery Mobile, pages example}
\label{fig:jquery}
\end{figure}

Creating two pages is quickly done, the downside of jQuery mobile is that in order to create an application where views look a like, you have to repeat yourself. You have to create pages with other id's and with the same look/elements but with different information. The conclusion is that jQuery mobile is that it is easy and the developer does indeed use HTML, CSS to create views.  But it is not easy to build a modular application. It is always possible to create such a modular application yourself, but when creating an application which is not such a framework the developer will run in to creating a framework in stead of the intended application.

\item [Sencha Touch 2]
Sencha touch 2 is a framework focused on the Model View Controller design pattern. It encourages the developer to use this pattern. The way of developing really differs from jQuery mobile. There where jQuery mobile sets you free to do whatever you like, sencha touch constraints the developer using components that are available in sencha touch. The difference can be easily explained with an example.

In the items array, see figure \ref{fig:sencha}, the items in that array can be anything supported by sencha touch like lists, a tabview, a map, etcetera. 

Sencha touch provides a command-line tool to build a starting environment. It creates files where the developer can start from. It's recommended to use this as a starting point. The advantage is an application that is structured out of the box with a design pattern that is the current standard(MVC). With Sencha Touch 2 there is no need for PhoneGap, unlike jQuery Mobile. Sencha Touch 2 provides the possibility to run the code on your simulator or native device with the command line tool. Testing for Android an iOS became much more simplistic resulting in less developing time. Running PhoneGap for Android, needs Eclipse to build, for iOS the developer needs to build in Xcode. When testing on both devices the developer needs to be able to test in both environments, and testing from the command-line is a lot easier than running both environments. 

A disadvantage of Sencha Touch could be, as seen in figure ~\ref{fig:sencha}, the syntax of sencha touch is not so easy at first. So the learning curve could be very steep.
The last argument that has a great influence on deciding which framework to use, could be that Sencha Touch provides an add-on that has the capability to create multi-touch charts. The original implementation of the urban flood browser on the multi-touch table has this feature. It would be a great extension of the project if this was possible. So with an eye on the future it could save a lot trouble, and it could add up to a more intuitive design. The next section will discuss this in more detail.

\begin{figure}[h!]
\begin{lstlisting}
Ext.application({
    name: 'foo',

    launch: function() {
        Ext.create("Ext.tab.Panel", {
            fullscreen: true,
            items: [
                {
                    title: 'bar',
                    iconCls: 'bar',
                    html: 'bar'
                }
            ]
        });
    }
});
\end{lstlisting}
\caption{Sencha Touch application example. This example creates an application with the name 'foo'.  The html can be placed inside the items array. }
\label{fig:sencha}
\end{figure}
\end{description}


\subsection{App Design}
The application will be used on tablets so a lot of space can be used. Working with tablets the screen gets larger than mobile phones. Which can result in a bigger travel distance of the user's hands. The GUI design has to be build with the considerations of the interaction capability of the users. For instance, unlike with mobile phones, according to Clark(2012) a leading designer in creating multi-touch applications, people intend to hold a tablet on the top halve of the tablet when holding with both hands, figure \ref{fig:perimeter}. The focus of the user is going from top to down. The top elements of the application will draw the first attention of the user. That's why Clark(2012) advises to place the important controls on the top half of the screen. The components that are important have to be placed in the left or right top of the screen. By taking Clark's advise the Flood Simulation Browser can be inspired.
\begin{figure}[ht]
\center
\includegraphics[scale=0.3]{touch.png}
\caption{Portrait touch perimeter(Clark, 2012)}
\label{fig:perimeter}
\end{figure}
First of all the flood simulations are within different cities. This can typically be a list of cities, also a list is scrollable and can be seen as an "infinite" array of cities around the world. Every city has it's own array of simulations to show. So it makes sense to also show these in a list. When a city is selected, the user has no use of the capability to select other cities and it's simulations. That's why the list of cities are pushed out of the viewport and the list of simulations is pushed in. 
It also makes sense to have one Map object in the view, where one city (latitude, longitude) can be shown at a time. The map object is the most important component of the browser. Inspired by Clark(2012) it can be stated that a hierarchy in importance of different view components can result in a different place on the screen. By placing the Map component always in the view and also as the biggest component, the idea of placing objects in a hierarchy of importance in the view is considered. For an example of this, see figure \ref{fig:mockup}.
The list component where cities and simulations are placed is the left side of the view, it could also be the right side but it would not matter. Since two hands are more or less symmetrical, so placing the list object left or right would not be a problem. It does matter concerning controls. Which controls shown in the top bar is not clear at this moment. Controls to change the image placed on the map are definitely needed. A simulation consists of multiple images on different time steps. By giving the user control of which image is seen at which time step is a crucial feature in the browser. Where and when(on which event) to place these controls is discussed in the final document.
\begin{figure}[ht]
\center
\begin{tabular}{c}
	\includegraphics[scale=0.2]{mockup1.png} \\
	\includegraphics[scale=0.2]{mockup2.png}
\end{tabular}
\label{fig:mockup}
\caption{Cities list of which simulations are available}
\end{figure}

\begin{figure}[ht]
	\includegraphics[scale=0.5]{chart.png} \\
\caption{Example of sencha chart}
\label{fig:sencha chart}
\end{figure}

The flood simulation browser that is already build for the multi-touch table has the ability to submit new simulations to be simulated in the cloud. The spot of the simulation can be arbitrary on the map, by simply touching a place on the map and alter some parameters, the cloud service can create a new simulation to be seen. Although this feature can be an seen as an extension of my project, with time left this feature can be build in. That's why it can be considered in the App's design. The controls of these parameters need to be somewhere in view, by placing this in the neighbourhood where the user touches the map could be intuitive. But not if it happens when the user is just navigating over the map, the user has to know that it is in the mode of with picking a place where to create a new simulation. The specification about these controls are discussed in the end report.

Furthermore, it's an important feature to display data of a simulation in certain area. The API provides this data. It holds information about how much water flows in that area over time. The API requests latitude, longitude values, it then returns data of a location that is closest to this point. The application needs to display this data in a clear and understandable way. Charts are great way to display this data. In development of this application there needs to be a clear understanding of what usability is. Only displaying a chart of certain values could not be enough to learn anything or draw conclusions about the flood. The goal is to make use of the Sencha Touch Chart framework in order to provide comprehensive data of a flood in a certain area. See figure \label{fig:sencha chart} for an example of the chart framework.

\pagebreak

\section{Conclusion}
The project will be implemented with the framework Sencha Touch 2. All encountered issues will be discussed in the end report. This information can be used in future projects relating to creating cross-platform applications. Also all data about the scalability of the server will be documented. The urban flood project can in turn use this data in future plans to invest in more server power. If they do not need to invest in more power this is also important.
This project will ultimately result in a cross-platform application that can be used by the public or government to gain information about a certain area.


