UPTEC F 17018
Examensarbete 30 hp
Juni 2017
Creating a usable analysis application
built on an existing visualization
platform
Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student
Abstract
Creating a usable analysis application built on an
existing visualization platform
Pontus Arfwedson
The advances in research on wireless communications has lead up to the current success of 4G mobile broadband and is currently focusing on designing the upcoming even more advanced fifth generation (5G) networks. The type of research behind this typically generates large quantities of data and requires efficient analysis in order to achieve tangible results. To enable this analysis, visualization of the data is used to give the researchers the needed insights. For this master thesis project an existing
platform will be analyzed with the goal of, by utilizing the platform, creating a powerful, useful analysis application with the necessary and desired tools. The platform can access data produced from research simulations and visualize them through different types of useful charts. However, it has up until now lacked some important functionality, mainly letting the user modify and alter the visualization to aid in the analysis. It furthermore requires knowledge and experience before being useful. To solve this, there existed a need of extending the platform with new tools and functionality to give the user more control and possibilities and to simplify the usage. The thesis resulted in a functioning analysis application that gives the user many necessary features to effectively analyze data. The result fulfilled the set requirements with improved and added views, extended tools and optimized performance.
Ämnesgranskare: Mikael Sternad Handledare: Pontus Arvidson
Popul¨arvetenskaplig sammanfattning
I en v¨arld d¨ar mer och mer data skapas beh¨ovs anv¨andbara verktyg f¨or att v¨al kunna analysera den. Forskning inom mobila n¨atverk har givit oss GSM, 3G och sedermera 4G men ¨ar mitt uppe i utvecklingen av framtidens n¨atverk, 5G. F¨or att effektivt kunna driva forskningen vidare kr¨avs kraftfulla simulatorer som modellerar den verklighet som unders¨oks och str¨avas efter.
I och med utvecklingen av femte generationens n¨atverk ¨ar det en uppsj¨o av f¨oretag och institutioner som tillsammans arbetar med att standardisera och forska fram hur n¨atverket ska se ut. De simulatorer som anv¨ands och utvecklas f¨or detta syfte genererar stora dataset d¨ar m˚anga relationer finns mellan olika typer av information. F¨or att kunna finna dessa slutsatser visualiseras data i regel med hj¨alp av MATLAB d¨ar en m¨angd olika script tj¨anar olika syften f¨or att skapa r¨att plot. Och gillar man att scripta sj¨alv, och har arbetat med dem mycket, ¨ar m¨ojligheterna n¨astintill o¨andliga. Men vill du fokusera p˚a att snabbt kunna visualisera data, speciellt om du ¨ar ny inom anv¨andandet, s˚a blir det extremt tidskr¨avande att ta till sig vad alla script g¨or och hur de fungerar. Vidare kr¨avs det att man har en djupare f¨orst˚aelse f¨or MATLAB f¨or att kunna ta fram de resultat man s¨oker efter. G˚ar det att r˚ada bot p˚a detta?
Ericsson har utvecklat en egen visualiseringsplatform d¨ar simuleringsdata kan importeras direkt in i applikationen. Den har inbyggd funktionalitet f¨or att relatera dataset samt support f¨or en m¨angd olika typer av grafer och filter. Under detta examensarbete har plattformen vidareutvecklats fr˚an just bara en plattform till ett anv¨andbart analysverktyg. Genom att ge anv¨andaren m¨ojlighet att dynamiskt och intuitivt best¨amma hur applikationen kan se ut ges denne mer frihet. Additionen av verktyg f¨or panorering, zoom och line tracking ger anv¨andarna en st¨orre m¨ojlighet att vrida och v¨anda p˚a det de ser. Resultatet innefattade ¨aven m¨ojlighet att automatiskt exportera grafer till Powerpoint, se log-utskrifter samt en inbyggd hj¨alp-video. Fokus l˚ag fr¨amst p˚a att g¨ora applikationen mer modifierbar och dynamisk f¨or att se till s˚a att varje anv¨andare, med enkel-het, kan f˚a den att fungera s˚a som han eller hon vill. Och om vi ska tro anv¨andartesterna s˚a var det precis s˚a det blev.
Acknowledgements
I would like to first and foremost thank my supervisor at Ericsson, Pontus Arvidson, as well as my line manager, Johan S¨oder, for their support, guidance and confidence in my work. Furthermore, my reviewer at Uppsala University, Mikael Sternad. Lastly, I would like to thank my beloved partner Magdalena Hillered for her undivided backing throughout this project.
Contents
1 Introduction 6
1.1 Data visualization . . . 6
1.2 Visual data analysis . . . 6
1.3 Existing platform . . . 7 1.3.1 hSQL database . . . 8 1.3.2 XML file . . . 8 1.3.3 FXML file . . . 9 1.3.4 JavaScript file . . . 9 1.3.5 CSS file . . . 9 1.4 Other applications . . . 9 1.4.1 OriginPro 8.5 . . . 9
1.4.2 IBM Many Eyes . . . 9
1.4.3 Sigmaplot . . . 10 1.4.4 Microsoft Excel . . . 10 1.4.5 MATLAB . . . 10 1.5 Usability . . . 10 1.6 Problem definition . . . 10 2 Theory 11 2.1 Java/JavaFX . . . 11
2.1.1 BeanProperties and Observables . . . 11
2.1.2 Performance . . . 12 2.1.3 Java 8 features . . . 12 2.1.4 Interface . . . 12 2.1.5 Singleton . . . 12 2.1.6 Inheritance . . . 13 2.1.7 RTTI . . . 13 3 Method 14 3.1 Examining the existing platform . . . 14
3.2 Studying the data model and data access . . . 15
3.3 Requirements analysis . . . 17 3.3.1 Interviews . . . 17 3.4 Prototyping . . . 17 3.5 Implementation . . . 17 3.5.1 Commenting . . . 17 3.5.2 Unit Testing . . . 18
3.5.3 Verification and validation . . . 18
3.5.4 Code Review . . . 18
4 Requirements 18
6 Result 21 6.1 Architecture . . . 21 6.2 Attribute relations . . . 22 6.3 Plot Tools . . . 27 6.3.1 Graph settings . . . 27 6.3.2 Line settings . . . 30
6.4 Data Source View . . . 34
6.5 Chart Chooser View . . . 37
6.6 Multiple graphs per tab . . . 41
6.6.1 Selecting the chosen graph . . . 43
6.7 Log View . . . 44
6.7.1 Subscribable Logger . . . 44
6.8 Application with all the views . . . 45
6.9 Graph interaction - Panning and zooming . . . 46
6.9.1 Scroll zooming . . . 47
6.9.2 Scroll panning . . . 49
6.9.3 Drag panning . . . 49
6.10 Line tracking . . . 50
6.11 Usable quick buttons . . . 52
6.11.1 Layout mode bar . . . 53
6.11.2 Cursor mode bar . . . 53
6.11.3 Reset axes button . . . 54
6.11.4 Toggle grid button . . . 54
6.11.5 Close graph button . . . 54
6.12 Tutorial view . . . 54
6.13 Power point exporter . . . 55
6.14 Adding filters . . . 57
6.14.1 Bad data removal . . . 58
6.15 Performance . . . 60
6.15.1 New Java 8 functionality . . . 61
6.16 Layout & design . . . 61
7 Conclusions 62 8 Future work 66 Appendices 69 A Interview questionnaire 69 A.1 Pre-questionnaire . . . 69
A.1.1 Q: What features (different charts, tools, scripts) do you always use in MATLAB when visualizing data? . . . 71
A.1.2 Q: Are there any features (different charts, tools, scripts) that you want to use in MATLAB but are complicated to get working the way you want? . . . 71
A.1.3 Q: Are there any features (different charts, tools, scripts) in, for example, MATLAB that you avoid using due to taking to much time? . . . 72 A.1.4 Q: What is the most important aspect of visualizing data
for analyzing in your eyes? What advantages do you get from it? . . . 72 A.1.5 Q: Do you generally feel pleased with the way you are able
to visualize your data in order to analyze it? . . . 73 A.1.6 Q: For finding correlation between different data - do you
have any ideas of ways to visualize data to achieve this? . 73 A.1.7 Q: Roughly how much of your time do you spend
graphi-cally setting up and observing data (such as graphs, plots etc)? . . . 74 A.1.8 SHOW GVP FOR QUESTIONEE! . . . 74 A.1.9 Q: What features do you immediately feel that GVP is
lacking? . . . 74 A.1.10 Q: Is the way the available data is shown in GVP clear
and easily understandable? If not, how would you prefer? (Show GVP for questionaree) . . . 75 A.1.11 Q: Do you feel a need for something more than ability to
save graph(s) as image? Export to a different format for further analysis or reporting? . . . 75 A.2 Post-questionnaire . . . 76
B Continuous testing form 77
1
Introduction
1.1
Data visualization
Data visualization has been around for almost 2000 years, starting with Astro-nomical information in tables in Egypt, and has since grown into something crucial for the way we can use the data we create [1]. It is now important for many applications and provides powerful tools to understand data and to communicate that data to others.
There are some current good reoccurring features that are trending in the way we visualize data. One prominent one comes in the form of analytics where the user is not only able to represent the data visually, but also interact with it and ”change its level of display” [1]. This lets us apply our eyes and brain in an effective way that can lead to insights otherwise hard to achieve. Since static visualizations do not allow for modification or alteration they work well for presentation but they cannot be utilized to their full extent for analysis. Not much intellectual work is achieved with our eyes and ears closed, like Ware mentions [2]. Utilizing them to the fullest is therefore of great importance when analyzing intricate data.
1.2
Visual data analysis
The field of data visualization has lead to the development of many different ways of analyzing data. It might however, when not applied properly, produce confusion rather than understanding. It is therefore important to account for many factors when trying to create a visual analysis application [1].
To make an analysis of something is defined as ”a systematic examination and evaluation of data or information, by breaking it into its component parts to uncover their interrelationships” or ”an examination of data and facts to uncover and understand cause-effect relationships, thus providing basis for problem solving and decision making” [3]. An application used for analysis must thus give the user the right tools to perform these very actions. When creating a modern analysis application there or many parts to take in account but it could be broken down into data model, data access, data transformation and user flexibility [4]. The data model should be designed to best represent the data that the application aims to aid in analyzing. For this choice the relational model is the most common one due to the fact that different sets of data tends to be related to other sets. For this model, relational databases are generally the way the go. And, in contrast to standard designed databases, de-normalized tables with some redundancy can be preferable to limit the work needed to access data.
Data access describes the way the analysis application retrieves the different data. This should create a coherence in the data so that the application can handle all the data in a similar fashion.
Data transformations are important features in any analysis tool and allows the user to modify the way the current data is used. For this case the sky is the limit but it is in many cases important to not do too much. The most commonly
used ones involve aggregation, counting and filtering, which generally covers most of the use cases.
Lastly, user flexibility is of utmost importance when designing an analysis application. If an application is too flexible, it generally tends to be cumbersome to use, while too limited flexibility does not allow the user to achieve what the user needs.
A user tends to explore data in a cycle of hypothesis, experiment and anal-ysis where the analanal-ysis might produce results or suggest the new hypothesis [4]. The user does also not generally care about how the data is stored or accessed. In some cases one might however need to consider expert users who could be using the application extensively, and more intricate features could therefore potentially be added to also satisfy this user. The designer could then add more flexibility which is hidden for a normal user, but could be accessed when needed or wanted. This way, an application can appear easy unless you use the advanced functionality. To make the application very flexible the user can learn, for instance, Standard Query Language (SQL) to query the data sources directly. This requires a high level of expertise. Another option is to use an abstraction layer, such as a Graphical User Interface (GUI), that gives the user access to transformations that the user can compose together to achieve the wanted result [5].
1.3
Existing platform
Ericsson Research is researching different new radio technologies, largely 3rd Generation Partnership Project Long Term Evolution (3GPP LTE) but also Bluetooth Low Energy (BLE) as well as the new upcoming radio technology for 5G, NR [6]. To enable this research they are using different simulation environments to apply models and techniques and study its performance. When performing such a simulation large amounts of data are generally produced from which the researcher is expected to make conclusions. In lack of an effective way of streamlining the analysis process MATLAB has been used to a large extent, where an abundance of scripts has been used to cover as much of the functionality as possible. This has however shown to be tedious and also difficult for a new user to learn. To tackle this issue Ericsson has chosen to develop its own Generic Visualization Platform (GVP).
The GVP enables data visualization and is specifically designed to support data generated using simulators, however can work for many other sorts of data. The built platform has a set of components that a user can apply to graph different charts and aims to enable easy extension by developing more components. It also provides the abstraction layer to the underlying data sources from the simulators which are stored in SQL-databases. A tool to identify relations between data sources has also been implemented which allows for detection of what data can be plotted together with what other data. This way helping the researchers to find relations. It creates all the necessary queries to achieve this by combining the needed tables and retrieve the wanted result.
It is developed in Java using their graphic library JavaFX with functionality compatible with Java 2 and later. It has functionality for multiple tabs with one graph per tab, see Figure 1, where a user can modify certain configuration files before starting the application to alter the type and number of tabs.
Figure 1: Example of the look of the original platform
It furthermore supports a context menu in which a user can, among others, save snapshots, edit relations and open a Settings dialog in which modifications to the graph can be made.
The existing platform is created around a model which utilizes five different types of resources apart from the actual source code, a hSQL database, a javascript file, an XML file, a CSS file and one or more FXML files.
1.3.1 hSQL database
The application needs data with a specific structure from a hSQL database in order to function and it uses this data as the sources for finding relations and for the actual visualization. The database could in theory be formatted in any way desired but to aid the relation finder the data has a defined supported structure that is easily generated from used simulators.
1.3.2 XML file
For every runnable application an XML file is needed. This XML file is the root that the application opens when being initialized and works as a metamodel of the data contained in the database. Furthermore, filters and different scenarios
in-cluding different datasets can be defined. This file is also generated automatically when running simulations according to the settings of the simulator.
1.3.3 FXML file
Through the application FXML file the static GUI layout can be defined before application launch. This way, the look and functionality of the application can be altered without modifying the actual source which enables a user to, for example, decide what graphs to be shown in the application. The format .FXML is defined by the JavaFX library.
1.3.4 JavaScript file
An application JavaScript file can be executed at runtime and works as a compliment to the FXML file. By creating instances of actual Java objects from the source code it can aid in performing actions at startup, such as generating a number of initialized tabs.
1.3.5 CSS file
The CSS file is used in the same way as when creating web applications, however with some differences in notations, as defined by JavaFX. In this file the general layout of all custom graphical objects is defined and it contains color schemes used to create a consistent look and feel of the application.
1.4
Other applications
Ericsson did review multiple other applications before deciding to develop their own visualization platform concluding that none of the existing application fulfilled all their needs or would maybe be to intricate and advanced for the use that was intended. However, these other applications can still serve as reference and inspiration for implementations of certain features.
1.4.1 OriginPro 8.5
OriginPro 8.5 is a Windows-based data and graphical analysis software [7]. It allows for a large amount of different 2D -and 3D-plots and supports data formats from, e.g., MATLAB and LabView through interfaces. It contains signal processing features such as FFT and others. It does however come with a hefty pricetag.
1.4.2 IBM Many Eyes
IBM Many Eyes was closed down in 2015 after being on the market for nearly 8 years [8]. It was mainly a visualization tool rather than focusing on analyzing data but could serve a great purpose for creating graphical interpretations of metadata and such. Therefore not the best suit for analysis of simulation data despite its creative features.
1.4.3 Sigmaplot
SigmaPlot is a graphing tool developed by Systat Software Inc that contains more than 100 different technical graph types and offers a wide array of modification possibilities [9]. It can be integrated with Microsoft Excel and can import data through ASCII plain text, comma delimited, SQL queries and more.
1.4.4 Microsoft Excel
Microsoft Excel is one of the most widely used softwares for graphical visualization and is popular due to being easy to program and operate, its graphs as well as calculations [10]. However, it tends to be cumbersome when working with larger datasets and cannot handle databases such as relational ones.
1.4.5 MATLAB
In scientific calculations, data analysis and visualization MATLAB is widely used and popular for its large amount of modules that focus on different areas of physics and mathematics. It is furthermore distributed to universities and companies through licenses that allows for many users. It allows for scripting, as well as object oriented programming, and can perform many tasks. However, to create an environment for a specific task might require many scripts which makes it difficult to keep general. Furthermore, to introduce new users to a set of scripts used for performing tasks can be hard if not using GUI and such. MATLAB does also store all the data in memory which can create issues for larger datasets with MATLAB causing out of memory. It is the most commonly used tool by Ericsson Radio Research for analyzing simulation data.
1.5
Usability
Creating a usable application is vital to maintain people using the application. ”Usability is a measure of the interactive user experience associated with a user
interface, such as a website or software application. A user-friendly interface design is easy-to-learn, supports users’ tasks and goals efficiently and effectively, and is satisfying and engaging to use” [11]. Usability describes how well a collection of features work, and how they together make the application a satisfiable one. It is generally best determined by the actual user base and there is therefore importance in finding out what the user of the application desire the most.
1.6
Problem definition
Ericsson has to a large extent chosen to use MATLAB for their visual analysis of simulation data. MATLAB offers great possibilities but also requires a thorough knowledge and is hard to make into a general and easy-to-use tool. This is why they decided to develop their own visualization platform, to enable demonstrations and analysis. This platform has interfaces for the data model,
the data access and transformations and has all that functionality accompanied by a number of components to represent certain types of graphs and tools. It does however not yet give the user the possibility of playing with the data and modifying it to aid in the analysis, and lacks many of the standard tools that a user would expect and possibly need. Can this visual platform be developed into a powerful and usable analysis application, and if so, how?
In this thesis I will study the limitations and possibilities in the platform and perform implementations to demonstrate the possibilities, but also in order to showcase potential limitations that could be crucial for the platforms further development. The preferable goal is to create a fully usable analysis application that researchers could use for their daily work. This needs to provide the necessary tools, but also be responsive and properly designed to be usable. New functionality in the Java 8 platform will also be studied and, if found to give improvements, be implemented.
2
Theory
2.1
Java/JavaFX
Java is one of the most popular object oriented programming languages that exists and is widely used for desktop and mobile applications - as well as for back end servers. It, as all the other object oriented languages, is built on the concept of object orientation with programmable objects representing entities or used to perform certain cohesive tasks. JavaFX is built on Java, by Oracle, and is a library that allows for development using existing graphical objects to represent layout - along with functionality tied to those objects [12]. In JavaFX there is a root node onto which everything else is placed. Every node, apart from the root, therefor has a parent node and none or a number of sibling nodes and children nodes. This way interaction between different nodes can be achieved and layouts can be altered and modified dynamically. It also implements FXML-files for static layout design and CSS-files for styling components in accordance to static definitions.
2.1.1 BeanProperties and Observables
Using BeanProperties and Observables enables a flow of information throughout the application that is extremely useful for having things trigger on events in different parts of the application. A Bean in java is defined as a Plain Old Java Object (POJO) that is serializable, has a zero argument constructor and public setters and getters [13]. This concept as been adapted by JavaFX with a BeanProperty class that has subclasses to encapsulate many types of objects by having subclasses such as StringProperty, BooleanProperty or SimpleObjectProp-erty for other types. Theses properties, furthermore, enables event handling that can trigger on change to the object. By defining a list as an ObservableList or a string as a StringProperty anyone can attach listeners to trigger on when those
objects are altered. It is a part of a concept called Reactive Programming which handles the function of different parts of the program reacting to other parts [14]. It enables laziness, in the sense that nothing is performed unless it needs to be performed. For example, an invisible view will only start getting updated from the flow of information once it turns visible. This way, good performance can be maintained.
2.1.2 Performance
Creating a JavaFX application with quick responsiveness and good performance can be cumbersome, but there are certain aspect of the structure of programming that make the application better [15]. Some of these include using as few nodes as possible, execute as little code as possible, do minimal work on the main FX thread and minimize text measurements. Together, all these form a mindset that, if applied by the developer, can make a vast difference on the way an application is performing.
2.1.3 Java 8 features
Java 8, that was released in 2014, contained several new features on top of pre-existing functionality, such as Streams. Streams allow the developer to transform any type of collection, such as a list, to a Stream, and apply operations onto that stream. It can fuse functions together making them into one single operation which only is applied whenever the Stream is collected back into a collection. By having functions for filtering, mapping and sorting, complex operations can easily be attached to a list in order to transform them. These streams can also become multi-threaded by a simple operation after which the Java Virtual Machine (JVM) that is running the application will try to perform the task in parallel [16]. This is highly advertised by Oracle but may have limited or no effect in many cases.
2.1.4 Interface
A Java interface is a group of related methods with empty bodies [17]. The methods can be implemented either by creating an instance of the interface, or by having a class implementing the interface. That way the compiler will force the class to contain implementations of the methods from the interface. Interfaces can be used to efficiently hide an objects functionality from another but also to allow for interaction with different types of objects that may have different implementations of the same interface.
2.1.5 Singleton
A singleton is a class that has no public constructors but only a method to get a static instance of the object, see Listing 1. The only way to retrieve an object of such a type is by using the provided public method that will instantiate the object the first time it is called, and henceforth return that same object. The
reason behind using a singleton is to allow the entire application to only use one and the same instance of that object. This way, its properties will be alike for all calling objects.
Listing 1: Example of a singleton
p u b l i c c l a s s S i n g l e t o n {
p r i v a t e s t a t i c S i n g l e t o n s i n g l e t o n ; /* *
* Get the s t a t i c i n s t a n c e of the s i n g l e t o n * * @ r e t u r n s i n g l e t o n */ p u b l i c s t a t i c S i n g l e t o n g e t I n s t a n c e () { if( s i n g l e t o n == n u l l) { s i n g l e t o n = new S i n g l e t o n () ; } r e t u r n s i n g l e t o n ; } p r i v a t e S i n g l e t o n () { s u p e r() ; } 2.1.6 Inheritance
Java, along with many other object oriented languages, implements inheritance meaning that an object can be a subclass, or a child, of a parent class, allow it to inherit certain attributes from the parent class [18]. To easily exemplify, when designing an application that models vehicles, the developer could implement a parent Vehicle class with two subclasses, Car and Truck. This due to the fact that both the vehicles share certain attributes, such as speed, direction and numberOfWheels. Along with this, some car -and truck specific methods that only apply to them can be implemented in the subclasses. This way, the developer to not have to care about the subclass type when setting its speed or direction, but only if attempting to access the methods from the subclasses.
2.1.7 RTTI
Run-Time Type Identification (RTTI) is the functionality that allows the devel-oper to identify the type of an object during runtime. This is used when trying to determine which subclass of a parent class a certain object belongs to. When applied in Java, the instanceof operator is used, see Listing 2. By using this operator and cast it to the identified object, methods from that child object not present in the parent can be executed.
Listing 2: Example of RTTI which would give output ”v1 is truck - v2 is car” if the Vehicle toString()-method would return the objects name. It would also execute the methods specific to those two subclasses
p u b l i c v o i d r t t i () { V e h i c l e v1 = new T r u c k () ; v1 . s e t N a m e (" v1 ") ; V e h i c l e v2 = new Car () ; v2 . s e t N a m e (" v2 ") ; if( v1 i n s t a n c e o f Car ) { Car car = ( Car ) v1 ;
S y s t e m . out . p r i n t ( car + " is car ") ; car . c a r M e t h o d () ; }e l s e{ T r u c k t r u c k = ( T r u c k ) v1 ; S y s t e m . out . p r i n t ( t r u c k + " is t r u c k ") ; t r u c k . t r u c k M e t h o d () ; } S y s t e m . out . p r i n t (" - ") ; if( v2 i n s t a n c e o f Car ) { Car car = ( Car ) v2 ;
S y s t e m . out . p r i n t l n ( car + " is car ") ; car . c a r M e t h o d () ; }e l s e{ T r u c k t r u c k = ( T r u c k ) v2 ; S y s t e m . out . p r i n t l n ( t r u c k + " is t r u c k ") ; t r u c k . t r u c k M e t h o d () ; }
3
Method
The conduction of this thesis can largely be divided into four different parts. The first part is the study of the existing platform and its architecture. Secondly, there will be a requirement analysis to decide what features to ultimately implement followed by prototyping these features. Finally, there will be a phase of implementation when the suggested features will be created and integrated into the existing platform. Throughout the implementation phase continuous testing will be performed to assure desired functionality and quality.
3.1
Examining the existing platform
The existing platform and implementation was in part studied through thorough usage of the application alongside reading all the specifications and written material. But it was mainly done by examining the existing code base to get
an understanding of the architectural design and code patterns to identify the best way to extend the current implementations, as well as add completely new features. Furthermore, a course was conducted at Ericsson Research, for new employees, where their main Radio Access Technology (RAT) simulator that use the platform was the subject. This helped create a better understanding of where the data used in the platform originates from and why it is structured the way it is.
3.2
Studying the data model and data access
The data model is a relational one and is defined as a set of tables that contains one or more primary keys. These primary keys are intended to relate different sets of data in order to enable graphing of different but related entities, see Figure 2.
Figure 2: Example of data model structure
These different tables all relate to one quantity in the output from a simulator and as can be seen, share one or more primary keys.
from simulations run with their RAT simulator.
The platform had an existing implementation of a data access abstraction layer that enabled choosing different quantities in the graphs based on the content of the database. The platform could enable logging of components which enabled output of every query that is being sent to the database, from which conclusions could be had about how the data access is constructed.
3.3
Requirements analysis
The requirements analysis was based on studying other existing platforms as well as getting an idea of what the researchers wanted. It focused both on concrete features to be implemented, but also on more soft values such as responsiveness and design.
3.3.1 Interviews
Interviews was conducted with multiple researchers at Ericsson Radio Research. A questionnaire with more in-depth questions as well as quicker yes and no questions was produced with the intent to get a better understanding of the needs of the researchers, how their work is today and what it could become (see Appendix A for the full questionnaire). The response from the conducted interviews created a basis for the requirements of the final application and what limited the researchers today.
3.4
Prototyping
Prototyping was done using the web application proto.io where different views and the core of the layout was conceptually created. This prototype served as a main concept for the the oncoming implementation but did not necessarily restrict the way features could be implemented.
3.5
Implementation
Implementation of the suggested features was done in an agile fashion where they were continuously evaluated, tested and documented. Some extreme pro-gramming concepts were applied with the objective to write the tests for certain parts before making the actual implementation. The concrete features were created in accordance with the existing architecture and thus implemented in the code were evaluated to be best suited.
3.5.1 Commenting
The code needed to succumb to commenting standards that is set by the develop-ment team at Ericsson Radio Research. This to keep the code self-docudevelop-mented and to facilitate easier understanding of what the implementations actually perform, and how.
3.5.2 Unit Testing
Unit testing was conducted for all the produced code in accordance with existing standards. Unit testing is done through the codes public methods which are executed and evaluated. However, when developing graphical applications, some parts of the code might be programmatically unreachable due to only being triggered by user interactions on the GUI. To aid in this a helper was created to also directly test certain private methods. The helper used a Java methodology called Reflection through which private methods can be acquired, executed and evaluated.
3.5.3 Verification and validation
Apart from the continuous testing done during the development, both manually and using unit testing, more thorough conceptual testing was also done for verification purposes. When implementations had achieved a reasonable result the application was continuously tested by a panel of researchers. The goal of this continuous testing was to make sure that the application stayed on track and satisfied the needs of its future and current users, this way making the result less biased on my own clouded judgment. The researchers where given a thorough guide on how to set up and get started with the application and where then asked to fill out a form, ranking different features and experiences on a scale from one to ten (see Appendix B). This was then conducted on a weekly basis to get a idea of the progress of the application and to make sure that things that worked well kept on working well, as well as identifying issues in order to solve those.
3.5.4 Code Review
The code was scrutinized via code review performed by senior researchers. This was done by other developers within the application community in order to ensure quality and code standards and to potentially bring the projects implementations into the main official branch of the code after completion.
4
Requirements
As a result of the conducted requirements analysis several requirements for the application were decided upon. They were set as guidelines for the further development and used when evaluating the initial goal.
• It shall enable the user to modify and alter any graph to their liking • It shall allow the user to dynamically modify the layout and functionality • It shall correctly relate different datasets to aid in selecting the attributes
on a graph
• It should provide tools to aid in and simplify the analysis of the graphed data
• It must be responsive to use without too much lag
• It should have an easy to use design with quick access to functionality • It may enable the user to export graphs to a PowerPoint presentation
5
Prototype
The prototype, created in proto.io, was the graphical result of the decided requirements. They indicated that certain features should be available and that those should be easily accessible by the user when analyzing using the application. This resulted in certain main decisions regarding the design.
• For the sake of getting a clear view of the underlying set of data a view showing that data should continuously be visible for the user. This view could also implement further functionality to allow the user to interact with that data, but with a main focus of simplifying the way the user views the data that the user is conducting an analysis of.
• In order to be able to modify the look of any graph on the fly the user should always have a view visible with tools for altering the graph. This view should be implemented so that settings changed in the view directly affects the correct graph, in other words, no need for changing a setting and then clicking Apply to get the change to have an effect.
• To enable the user to quickly change between different graphs a drag-and-drop view should be visible containing different types of graphs that the user can choose from. These graphs will be based on the ones already implemented in the platform and by dragging and dropping one onto a current graph (or empty view), a graph of that type will appear and be ready for plotting data.
• To allow the user to choose what views to see there should be possibilities to change the sizes of the windows in order to let the user prioritize what view the user feel is the most important. For example, if wanting a larger graph, the user can resize the other views to take up little space in order to enlarge the graph.
These four main decisions regarding the design resulted in the initial proto-types. The prototype of the application with a default look can be seen in Figure 3 and it shows a central view where a graph would be, a left view showing the data sets, a top view with different types of graphs as well as a right view that would contain tools for the graph.
Figure 3: Prototype of the main view of the analyzer application As the application also strives to allow the user to alter its look, depending on the users preferences, hide buttons were placed at the secondary views in order to minimize them so that more room is dedicated for the main view of the graph. This can be seen in Figure 4 where the two side views have been minimized.
Figure 4: Prototype of the analyzer application with the visibility of the side views removed
Further on, a Log View was thought of in order to enable log outputs for a user that has no access to a debug environment, for example a user running the application as an executable. The platform contained built in functionality for toggling logging on and off for graphs, and if set to on, logs were printed in the System output of the application. This output is however only available if the user runs the application with a command window or through an Integrated Development Environment (IDE). For ease of use and distribution, running executables might be preferable, and in such a case enabling log output in the actual application could be desired. This view was not laid out in the prototype layout.
These prototypes were created before the actual features were implemented and served, when applicable, as strong guidelines for how the implementations were to be made. They did not however restrict the implementations in any way, and if other solutions were deemed better they could be implemented even though they were not on par with the prototypes.
6
Result
6.1
Architecture
The main architecture and conceptual design of the application was created before implementations began and served as an aid in keeping up the structure of the created functionality. However, due to certain things being implemented
within existing code, and other in new modules, it was not used to limit the possibilities but could be reviewed and altered as insights and new knowledge was acquired throughout the process. The main feature of the design was to encapsulate the existing platform within the extended functionality rather than adding all the new features to the existing ones, which can be seen in Figure 5 where the Visualization Platform represents the original encapsulated implementation. An extensive amount of changes where however also made to parts of the original code in order to achieve desired functionality.
Figure 5: View of the high level architecture of the implemented application
6.2
Attribute relations
In order to achieve correct relations between different attributes there was a need to implement a way to restrict which attributes the user could plot related to one another. The already existing relation finder used the primary keys (see Figure 2) to create relations between different attributes. This did however only differ between different data sources as a whole, and not between the individual
attributes that those data sources are constructed of. This resulted in the possibility to plot an attribute as a function of a primary key associated with a different data source than the original attribute. This may sound like something reasonable but due to the nature of the stored data, these primary keys are subsets of the same set, but not necessarily equal.
For example, suppose that we have two related data sources, see Figure 6, containing two main attributes, bitrate and coordinate, as well as a number of primary keys. We could then relate the bitrate to the cellId by using the four primary keys in the Bitrate table, matching them to the same keys in the CellCoordinate table and get the cellId :s.
Figure 6: Example of two related data sources with the primary keys in bold text
In this case it would give us that we have bitrate = 1000 for cellId = 2 if we aggregate the result as far as possible.
If we however want to find the bitrate for every user, then it is important to get the bitrate for every user in the Bitrate table, and not try to make it
as a function of the userId in the CellCoordinate table. This due to the fact that these are both a subset of all the users, but not necessarily, and not in this case, the same subset. The implemented feature does therefore enable so that a user may only be able to select appropriate attributes with one another. When selecting the Y attribute, the user can choose in all the data sources between all the attributes. For example, a user can select objectBitrate, see Figure 7.
Figure 7: Selecting the Y attribute, here able to select between every attribute. When the user thereafter selects an X attribute the user is not allowed to chose between the same attributes as before, see Figure 8. Will here denote the already chosen Y attribute attrY, its data source Y, and other possible attributes
as attrN for its corresponding data source N. I will further denote an attribute
that is a primary key pki, and define its presence in a data source N as pki∈ N .
The set of all primary keys is denoted PK and two related attributes can be expressed as Rel(attrK, attrN). At this stage when have selected attrY as the
Y attribute, the user can select the X attribute as one of these three different types.
• Can select an attribute attrN if attrN = pki ∈ Y
• Can select an attribute attrN if attrN = pki∈ Y ∈ N and Rel(attr/ Y, attrN)
• Can select any attribute attrN if attrN ∈ P K and Rel(attr/ Y, attrN)
So in the case of Figure 8, the user first selected objectBitrate. To conform to the previously stated rules, the user should afterwards only be able to select primary keys from the data source of objectBitrate, other related primary keys of other data sources or related non-key-attributes of other data sources. In the figure we can see that the user can select between five keys in the actual objectBitrate data source, two other keys from the cellZCoordinate data source as well as all the
non-key-attributes of the other data sources, such as mobileStartPositionX/Y/Z, cellX/Y/XCoordinate etc.
Figure 8: After selecting the Y attribute, selecting the X attribute. Now filtered so that only reasonable attributes show up. Only primary keys of the selected Y-attribute, as well as those that only exist in other data sources, and the main attribute of those sources
With this implementation and improvement ambiguous plots could be pre-vented by only allowing proper creation of relations between different attributes. This can be exemplified and visualized in Figure 9 where the same attribute as previously is marked green and is the chosen Y attribute, the blue ones are keys from the same data source, purple one are other keys in other data sources and yellow ones are regular attributes of the other data sources. Furthermore, attributes with a red line are not selectable. In this case there can be observed that same keys in other data sources can in theory be selected from either of those data sources. However, in the actual implementation this simply depends on where the search algorithm looks first and is able to establish the relationship. This could potentially result in more or less data points in the result but should, with proper output from a simulator, not make a difference. And important to note is that it will never affect the correctness of the result, only the magnitude of it.
Figure 9: Overview of example of primary keys and data sources showing a selection of the green objectBitrate and the three different related and selectable attributes
6.3
Plot Tools
The view containing tools for altering the graphs and their components was prototyped to be located to the right hand side of the application, be able to be expanded and minimized, and continuously react to changes in the graph as well as immediately apply changes to the selected graph. The visual platform that the analysis application is based on did have a settings functionality as a dialog window, see Figure 10. This was reached by right-clicking the graph and selecting Settings. This view was then populated and rendered when enabled and had no need to be synchronized to the properties of the graph unless it was shown. The changes then effected the actual graph whenever the button Apply was clicked. This was however deemed insufficient since it does not give the user a continuous overview of the graph the user is currently analyzing. Furthermore, by implementing ability to modify components within the actual graphs the settings were extended with settings to modify lines and legends.
Figure 10: View of the old settings view for a graph LineChartComponent
6.3.1 Graph settings
In order to achieve Plot Tools that possibly are visible all the time the func-tionality needed to initially be mimicked in order to achieve the wanted result
without affecting the architecture. The same set of settings was taken from the dialog window and moved to a view incorporated in the application, see Figure 11. What is shown for a particular component was already defined for the platform and has not been altered.
Figure 11: View of the application with the Plot Tools for a graph LineChart-Component
The previous functionality allowed for right-clicking on a specific graph and then showing the settings for that graph. For these updated Plot Tools there was a need for the view to be able to identify which graph was in focus. The analyzer therefore needed to always keep track of one component which currently is the selected one. This took several iterations and always added complexity when more functionality was added. Certain actions needed to trigger the switching between selected graphs and many scenarios had to be handled. This functionality evolved throughout the process and will be described more further on.
One further aspect was to have the settings continuously apply made changes to the graph, as well as changing whenever the graph changes. The initial implementation of the platform had a well defined architecture of configurations for graphical components and was used and altered for this purpose. Rather than loading the attributes of the graph into the settings view when shown
and setting the attributes on Apply, the attributes were simply bound to one-another to create a one -or bidirectional relationship. This was achieved by using an abstraction in JavaFX called BeanProperties. These act as placeholders for an attribute of a defined data type but also allow for invalidation -and changelisteners as well as bindings to other properties of the same kind. An example would be to change the name of a component through the name text field in the Plot Tools. This property can only be changed in the tools, not in any way by interacting with the graph. They therefore do not need to effect each other bidirectionally but only in one way. This can be achieved as in Listing 3 by having the text field setting its text to the property and then attaching a listener that makes sure that the property always has the same value as the altered text field.
Listing 3: Example of connecting a text field to a string property n a m e T e x t F i e l d = new T e x t F i e l d ( c o m p o n e n t . g e t N a m e () ) ; n a m e T e x t F i e l d . t e x t P r o p e r t y () . a d d L i s t e n e r (new C h a n g e L i s t e n e r < String >() { @ O v e r r i d e p u b l i c v o i d c h a n g e d ( O b s e r v a b l e V a l u e <? e x t e n d s String > o b s e r v a b l e , S t r i n g o l d V a l u e , S t r i n g n e w V a l u e ) { c o m p o n e n t . s e t N a m e ( n e w V a l u e ) ; } }) ;
Sometimes, however, a property can be altered both from interactions with the graph, as well as through the Plot Tools. An example of this is the bounds of the axes that can be set in the Plot Tools, but that also changes when a user zooms or pans in a graph. To make so that the bounds in the tools change when the user pans, but also make the actual axes change when a user alters the value in the tools, a bidirectional bind can be applied, see Listing 4. It uses the JavaFX library Bindings to create the binding and when applied makes sure that a change on either side will bubble up to the other property. This can either be done by having the same type of properties on each side, but can also be achieved using a converter when the properties are of different types. When, for example, converting a String into a number the used Locale is important, which defines in which format the String displayed the number, something that differs between different countries. The key in this case, if controllable, is simply to be consistent.
Listing 4: Example of bidirectionally binding a textfield to a number property S t r i n g C o n v e r t e r < Number > c o n v e r t e r = new
N u m b e r S t r i n g C o n v e r t e r ( l o c a l e ) ;
B i n d i n g s . b i n d B i d i r e c t i o n a l ( t e x t P r o p e r t y 1 a () , n u m b e r P r o p e r t y 1 b () , c o n v e r t e r ) ;
By applying both of these techniques a fully functional tool window could be implemented that is in continuous synchronization with the selected graph. 6.3.2 Line settings
To further extend the functionality of the Plot Tools an ability to alter elements within a graph was added. These settings are reached by clicking on an item in the legend, see Figure 12. Within this view there is the ability to modify the text of the legend item and set the width of a graph element, such as a line or dot. The color of the element can also be altered, see Figure 13 as well as the visibility, see Figure 14.
The graphs and its graphical elements have been implemented in a certain way in the pre-existing architecture and they were not designed with the option of modification in mind and are therefore hard to persistently modify. To achieve this functionality a top level ”pipe” was therefore implemented through which every selected graph is sent before being shown. This pipe must keep track of all the existing, possibly modified, graphs and is therefore updated as soon as graphs are added or removed. It acts as a layer that is put on top of the graphs and alters properties of the them before they are shown. This way the desired functionality for the application could be achieved without making any larger changes to the core architecture of the platform. And since these changes are mainly visual, there is no need to alter the actual objects but only to modify them before showing.
Figure 12: View of the application with the Plot Tools for a line in a LineChart-Component. Note the highlighted legend item that has been clicked to show this view.
Figure 13: View of the application with the Plot Tools for a line in a LineChart-Component with the Color Picker expanded and a new color selected
Figure 14: View of the application with the Plot Tools for a line in a LineChart-Component with the line set to invisible
The Plot Tools always shows settings for a graph, as long as there is a graph open. However, if the application is initialized without any graphs or if they are all removed the Plot Tools will get empty and enter a loading state, see Figure 15. This state will be maintained for as long as there is no graph opened.
Figure 15: View of the application with the Plot Tools when no graph is open
6.4
Data Source View
The Data Source View was constructed with the main purpose of giving the user an overview of existing data but to also have functionality for adding that data to a desired graph. The resulting view consisted of an expandable list of the different data sources, see Figure 16. These data sources then contained its own attributes which can be clicked in order to add as an attribute to a graph, see Figure 17.
Figure 16: View of the application with the Data Source View showing. The Data Source View gets the data sources from the first graphical compo-nent that is opened in the application and is thus empty, and loading, whenever there is no graph open in the application, see Figure 18. By design of the existing platform, every graph always has access to the same set of data sources and the view will therefore not have to re-populate the list when a user is switching between different graphs.
Figure 17: View of the application with the Data Source View showing and the user selecting to add an attribute to a graph
Figure 18: View of the application with the Data Source View showing but no graph open
6.5
Chart Chooser View
The Chart Chooser view was prototyped to be located at the top of the application with a visual list of charts to choose from. This to make it easy for a user to on the fly select new types of graphs to use. The list was implemented for a number of graphs, see Figure 19, and given drag-and-drop functionality to add a chart in order to then create plots in a graph of that sort. Given an application that initializes with no existing tabs, a chart can be dragged onto the Tab Bar which creates a new tab containing a graph with the chart that was dropped. When this is done, the application contains one tab. Another chart can now be dragged, either onto an existing graph to replace it within the context of the tab, or onto the Tab Bar to add yet another tab, resulting in two tabs, see Figure 20. Every tab will be named the same as the original graph that it contained but every tab has functionality to move its position and rename it, see Figure 21.
Figure 19: View of the application with the Chart Chooser View showing with no graph added
Figure 20: View of the application with the Chart Chooser View showing with 2 tabs added
Figure 21: View of the application with the Chart Chooser View showing with 2 tabs added
The Chart Chooser view does not contain enough types of charts to fill up the width of the application, unless its width is considerable reduced, but the view contains a list and is scalable in the sense that more charts easily can be added. Had there been enough charts to fill the width and more, the user could be able to navigate between them by side-scrolling the list of charts.
The drag and drop functionality was implemented by adding an EventHandler to all the items of the list of graphical objects in the view that can trigger on detection of a drag. Once a drag is commenced, a DataFormat object is added to a DragBoard, which is a built in functionality in JavaFX. When the user has the mouse pressed down and is performing a drag, elements in the application can have implementations of a DragOverEventHandler that triggers as soon as a drag is dragged over that object. This way, the cursor of the application can be altered when the drag is over certain objects, indicating to the user where the dragged object can be dropped. If dropped on an object that has an implemented DropEventHandler, that object will check that the dropped format is of a correct type and then perform actions. This way, for example, a Line Chart can be dragged onto a graph and there will then be a line chart on that
6.6
Multiple graphs per tab
The Chart Chooser will, as previously shown, create tabs that initializes as one single chart. In many cases a user might however want to have multiple graphs visible at the same time to more easily be able to compare them. This can be achieved by the user by using the buttons above the graph content. These buttons are Radio Buttons, meaning that one and only one of them can be enabled at a time, giving the user the ability to change how many graphs to show, and with which layout. The six current supported layouts are
• Single Graph - One single graph
• Two graph horizontal - Two graphs, next to each other, horizontally • Three graph horizontal - Three graphs, next to each other, horizontally • Two graph vertical - Two graphs, next to each other, vertically • Three graph vertical - Three graphs, next to each other, vertically • 2x2 matrix - Four graphs in a two-by-two grid
where the last one, the two-by-two grid, can be seen in Figure 22. The different layouts are always composed of SplitPanes, which are graphical views with separators that can be dragged to alter the size of the different components. Therefore, the user can always resize the graphs to his or hers preference, see Figure 23.
Figure 22: View of the application with the Chart Chooser View showing and a 2x2 grid view of graphs
Figure 23: View of the application with the Chart Chooser View showing and a 2x2 grid view of graphs where the sizes of the charts have been modified, and a second chart has been added. Also note that the topmost chart is the selected one, with a remove-button in its top-right corner.
An empty part of the layout will always contain the text Drag and drop a component until a graph has been added to that part, see Figure 23. When a graph is selected it can be removed by clicking the remove button, and that part will become empty.
6.6.1 Selecting the chosen graph
Keeping one chart as the selected chart has been mentioned previously and is mainly important in order to maintain the correct information and layout for the Plot Tools view. This is handled by a property in the analyzer and can be set in multiple ways.
• Whenever a new tab is selected, the first graph in that tab will be the selected one
• If a selected graph is removed, the first graph in the same tab will be selected
• If a user interacts with a graph, then that graph will become selected • If the selected tab has no graphs, there will be no selected graph
• If there are no tabs, there will be no selected graph
How a user can interact with a graph will be presented in section 6.9 and the effect of having no selected graph sets the Plot Tools and Data Source view in empty loading mode as described in section 6.3 and section 6.4.
6.7
Log View
To allow a user to easily get more insight about what is happening to certain objects in the application a Log View was implemented. It was not laid out in the prototype design but was chosen to be placed in the bottom center of the design. It initializes as an empty window, with the message No logs yet.., and can be resized like all other windows and contains a Clear button to clear the log and start from scratch, see Figure 24. The Log View uses a created Logger as well as a LogSubscriber interface to receive all the wanted logs from the application.
6.7.1 Subscribable Logger
The logger used by the Log View is implemented as a static singleton-class, in other words, one instance of the object for the entire application. The object contains one StringObject field that is set by the application as soon as a log message is being logged. On this field, an InvalidationListener was attached to perform an action whenever the string is being altered (invalidated). By allowing other classes to subscribe to the logger via an interface, LogSubscriber, and mapping each subscriber to a unique listener, the Logger can maintain a set of listeners connected to each subscriber and also support unsubscribing. Each class using the LogSubscriber will implement the interface and receive every log message in the defined method and can then choose what to do with it. Logging can be enabled and disabled for each graphical component and can also be implemented wherever desired within the application.
Figure 24: View of the application with a filled Log View in the bottom
6.8
Application with all the views
All the new and added views described throughout the result together form the major additions to the new and improved GUI. They all combined allow the user to overview the current data, to alter settings for graphs, add further graphs as well as inspect log outputs. And these views all surround the only original view, the actual graph, see Figure 25.
Figure 25: View of the application with all the major views
A user can, as described, resize all the views by dragging the separators between all the views. This way, the user can enlarge parts of the application he or she finds more important for the time being. Certain views have a defined maximal size, depending on its content, which in cases can prohibit further enlarging. There is always also a possibility to click the View button in the topmost part of the application and use the menu to select and deselect each of the views to completely remove them or add them back to the GUI. This to further allow the user to modify the look and feel of the application.
6.9
Graph interaction - Panning and zooming
One important aspect of the application was to enable the user to play around with the visualization of the data and to have access to basic functionality such as panning the graph as well as zooming. These are enabled to the user by the hotkeys
• CTRL+Scroll - Zoom • CTRL+Drag - Pan • Scroll - Pan up&down • ALT+Scroll - Pan left&right
6.9.1 Scroll zooming
Zooming using the scroll is enabled by holding down CTRL while scrolling. When scrolling up, the view is zooming in, and when scrolling down it is zooming out. The graph will zoom with a certain factor for every scroll and will do so by scaling the axes of the graph. This is done by making the place where the user has the cursor maintain the same ratio within the graph, enabling for the user to aim the zoom at a certain object, see Figure 26.
Figure 26: Example of use of scroll zoom, showing that a zoomed object in focus keeps the aspect ratio - in other words, remains on the same place despite being enlarged.
This is achieved by calculating new xstart, xend, ystart and yend and then
scale the axes to those. To exemplify, if xcursor is the cursors x-coordinate and
the scalefactor is a floating number that indicates the scroll speed, calculating the new length of the x axis
xlength= xupper− xlower
where the ratio of where the cursor is on the axis is ratiox= xcursorxlength−xlower
and the new length of the axis is xlength,new= xlength∗ scalef actor
After this, the starting x value is calculated by
xstart = xcursor − ratiox ∗ xlength,new = xcursor − xcursorx −xlower
length ∗ xlength ∗
scalef actor = xcursor− (xcursor− xlower) ∗ scalef actor
and the ending x value of the axis by
xend = xcursor + (1 − ratiox) ∗ xlength,new = xcursor − (1 −xcursorx −xlower
length ) ∗
xlength∗ scalef actor = xcursor − (xlength− xcursor + xlower) ∗ scalef actor =
xcursor− (xupper− xcursor) ∗ scalef actor
With these new values the range of the axis can be set, and if done for both the Y and X axes, will create a more zoomed in (or zoomed out) view where the focused object, i.e. the position of the cursor, remains in the same position as before.
6.9.2 Scroll panning
Panning using the scroll is enabled by either simply scrolling or by holding down ALT while doing so which results in a sidewards pan. This was simply implemented by calculating a scrollspeed, depending on a defined value and the axis range, and then adding or subtracting that to the end-values for every scroll and setting the new range. The reason to use the scrollspeed is to maintain a reasonable speed for scrolling both upwards, downwards and sidewards. Since the axes may have vastly different ranges a static speed for all cases cannot be used since it may scroll too fast or slow in either direction and not make for a pleasant experience.
6.9.3 Drag panning
Panning using the mouse is enabled by holding down CTRL and pressing the mouse on the graph and holding it down while moving it which results in the axes continuously changing in accordance to how the mouse moves. For this feature the functionality needed to take into account that it deals with two different metrics - both the actual cursor coordinates, within the context of the application, as well as what that corresponds to in terms of actual axis locations.
A factor between the axes range and the actual height and width of the graph was calculated by xf act= xlength widthgraph yf act= ylength heightgraph
and by keeping track of every cursor location and using that for the next calculation, a delta could by calculated by
dx = (xcurrent− xlast) ∗ xf act
dy = (ycurrent− ylast) ∗ yf act
which then creates the new xstart, xend, ystart and yend by
xstart,new = xstart,old− dx
xend,new= xend,old− dx
ystart,new= ystart,old+ dy
yend,new= yend,old+ dy
which then constitutes the axes new ranges. The reason for subtraction in x direction and addition in y direction is that this coordinate system, as most other graphical layouts, has the origin in top left corner rather than the bottom left that typically is used in graphs and such. The y axis therefore increases visually downwards, contrary to the usual upwards increase. The x axis on the other hand grows rightwards in both the cases.
6.10
Line tracking
A line tracker was implemented to improve a users possibility to quickly find the values of data points within the analyzed data. It works for multiple number of datasets within a graph simultaneously and will automatically select the data point closest to the cursor, as long as the cursor is within the boundary of the graph, and show the name of the dataset along with its X -and Y value for the chosen data point, see Figure 27. It can be enabled either by the selecting the cross-hair shaped cursor or by, with any cursor, pressing down ALT+Mouse1 and moving the mouse across the data points.
Figure 27: View of the application with the line tracker in use, showing the name of the series as well as the X and Y value of the selected data point.
The line tracker was implemented by keeping track of the current cursor position, and for every time the cursor is moved, iterate over all the data and select the data point that is closest to the cursor. And when done so, show a Popup window with information about the data point. Every time the popup is shown, its width is measured and the anchor point, meaning the coordinate to which the popup is attached to, is calculated. To avoid bad visualization these are used to, when needed, flip the popup horizontally, see Figure 28. This has to be done if the application is positioned close to the edge of the actual display and the popup will be extended outside the displays bounds. By inverting the popup whenever needed it always accurately anchors the correct data point and shows the correct information, no matter where on the screen the application or the data point is.
Figure 28: View of the application with the line tracker in use, where the popup window has been flipped due to too close to the displays edge.
6.11
Usable quick buttons
To simplify the usage for users and give them easy access to certain functionality a number of quick buttons were implemented. Most of them have been mentioned in previous sections when applicable but all together make up an important part of the interface the user has towards interacting with one or multiple graphs in order to efficiently analyze a given dataset. They are all located in the vicinity of the graph to simplify use, see Figure 29, and some are designated to the entire tab whereas some are unique for every graph.
Figure 29: View of the application with all the different types of quick buttons highlighted. BLUE - layout mode, RED - cursor mode, GREEN - reset axes, ORANGE - close graph and PURPLE - enable and disable grid.
6.11.1 Layout mode bar
The Layout mode bar is a tab property and therefore every tab contains one and only one. Its purpose is to enable the user to select the layout of the tab with the possibilities of several horizontal, vertical and grid layouts. Its state can be different between different tabs, depending on what the user has chosen, but a selected state for a tab will stay selected until a different state has been selected on that same tab. The reasoning for this should be obvious but is simply to give the user the possibility to have different layouts for different tabs, all at the choice of the user.
6.11.2 Cursor mode bar
The Cursor mode bar is more of an application property, however requires at least one tab in order to be present. Its purpose is to enable the user to select the functionality and look of the cursor, ranging from a normal arrow, a hand to enable drag panning or a cross-hair to enable line tracking. Its state is the same across all tabs and is thus independent of which tab is chosen. The reason behind this is to have consistency even when the user is switching between tabs since the user might want to perform the same action, but only on a different graph.
