D3.2 Method Modeling and Visualisation for the Urban Decision-Maker

D3.2 METHOD MODELING AND VISUALISATION FOR THE URBAN DECISION-MAKER

PROJECT

Acronym: UrbanData2Decide Title: Data Visualisation and Decision-making Solutions to Forecast and Manage Complex Urban Challenges Coordinator: SYNYO GmbH

Reference: 847511 Type: Joint Programme Initiative Programme: Urban Europe

Start: September 2014 Duration: 26 months

Website: http://www.urbandata2decide.eu E-Mail: [email protected]

Consortium: SYNYO GmbH, Research & Development Department, Austria (SYNYO) University of Oxford, Oxford Internet Institute, UK (OXFORD) Malmö University, Department of Urban Studies, Sweden (MU) Open Data Institute, Research Department, UK (ODI) IT University of Copenhagen, Software Development Group, Denmark (ITU) ZSI Centre for Social Innovation, Department of Knowledge and Technology, Austria (ZSI)

D3.2 URBAN DECISION-MAKER

DELIVERABLE

Number: D3.2

Title: Method Modelling and Visualisation Design for the UrbanDecisionMaker Report

Lead partner: IT University of Copenhagen (ITU)

Work package: WP3: Method modelling, Visualisation Design and framework elaboration

Date: September 2015

Authors: Joshua Ddamba, ITU Yvonne Dittrich, ITU

Contributors: Julia Neuschmid, SYNYO

Reviewers: Jonathan Bright, OII

The UrbanData2Decide project is co-funded under the Joint Programming Initiative, 2nd call Urban Europe.

D3.2 URBAN DECISION-MAKER

TABLE OF CONTENT

1 Introduction ...... 6

2 Modeling Approach ...... 7 2.1 Choice of Modeling Notation ...... 7 2.2 Modeling the UrbanDecisionMaker ...... 9

3 Analysis of National Concepts ...... 10 3.1 Preparing for Decision-Making and Collaborative Decision-Making ...... 10 3.2 Classifying the Sub-Features of the National Concepts ...... 11 3.3 Mapping of Sub-Features from the National Concepts to the General Activities Classified ...... 23

4 Roles in Decision-Making from the National Concepts ...... 25

5 Basic Design Concept Metaphors ...... 28

6 The UrbanDecisionMaker Use Case ...... 32 6.1 Actor Descriptions ...... 32 6.2 Actors Use Case ...... 33 6.3 Use Cases ...... 34 6.3.1 Create Decision Space ...... 34 6.3.2 Browse and Add Visualisation ...... 35 6.3.3 Add Collaboration Features ...... 36 6.3.4 Create Dashboard ...... 37 6.3.5 Sharing Visualisations...... 37 6.3.6 Take a Snapshot ...... 38 6.3.7 View Snapshot History ...... 39 6.3.8 Engage in Discussions ...... 40 6.3.9 Sign up for Alerts Features ...... 41 6.3.10 Save Image over Visualisations ...... 42 6.4 Class Diagram ...... 43 6.5 Mapping of National Concepts and Use Cases ...... 44

7 Existing Technologies ...... 45 7.1 Content Management Systems ...... 45 7.2 Web Development Frameworks...... 46 7.2.1 PHP ...... 46 7.2.2 Yii ...... 46

D3.2 URBAN DECISION-MAKER

7.2.3 Zend ...... 48 7.2.4 Symfony ...... 49 7.2.5 Laravel ...... 50 7.2.6 Phalcon ...... 51 7.2.7 CakePHP ...... 52 7.2.8 CodeIgniter ...... 52 7.2.9 Comparison of PHP Frameworks ...... 53 7.3 JavaScript Frameworks ...... 55 7.3.1 AngularJS ...... 55 7.3.2 Backbone ...... 56 7.3.3 Ember ...... 56 7.3.4 Comparison of JavaScript Frameworks ...... 56

8 Conclusion ...... 57

References ...... 58

Abbreviations ...... 58

D3.2 URBAN DECISION-MAKER

LIST OF FIGURES

Figure 1: Generic activities in urban decision-making (Deliverable 2.5, p.33) ...... 11 Figure 2 : Urban decision-maker use case diagram ...... 33 Figure 3: Typical workflow in a Yii application ...... 47 Figure 4: MVC with the Laravel framework ...... 50 Figure 5: Comparison of performance of PHP frameworks ...... 52 Figure 6: Most promising PHP frameworks for 2014 ...... 54 Figure 7: Google Trend Analysis of popular PHP frameworks ...... 55 Figure 8: Google Trend Analysis of popular JavaScript frameworks ...... 57

LIST OF TABLES

Table 1 : Mapping national concepts to the classification of decision-making features ...... 12 Table 2: Common features from the national concepts ...... 23 Table 3: Mapping of national concepts to generic decision-making activities ...... 24 Table 4: Roles of actors in decision-making identified from national concepts ...... 25 Table 5: Mapping of national concept features to the use cases of the UrbanDecisionMaker ...... 44 Table 6: List of existing content management systems ...... 45 Table 7: Features of the Yii environment ...... 47 Table 8: Features of the Zend Framework 2 ...... 49 Table 9: Features of the Laravel Framework ...... 50

D3.2 URBAN DECISION-MAKER

1 INTRODUCTION

The different national concepts presented for supporting each cities’ decision-making contexts and visualisations, offer a number of common features. This chapter identifies similarities between the different concepts to further amalgamate them into a common reference model. To achieve this, the report presents a structured and systematic approach of integrating the different concepts. It represents the results in the form of use case diagrams and use case descriptions.

Based on the use cases derived from the national concepts, the central outcome of reference architecture begins to emerge. The reference architecture will not fully describe a concrete system but will identify clusters of functionality needed to provide the use cases.

Deliverable 3.1 describes the modelling and specification of the visualisations, whereas this deliverable 3.2 presents the interface to the UrbanDataVisualiser and the UrbanDecisionMaker functionality. We chose the concept of a ‘visualisation’ as defining the interface between the UrbanDataVisualiser and the UrbanDecisionMaker. A visualisation is defined by a data set and the functionality and meta- information necessary to represent it. Whereas the Visualiser designed in deliverable 3.1 focuses on the analysis, aggregation, and the definition of the representation of the data, this deliverable focuses on the arrangement of different visualisations to support sense making, cooperation and structured discussions to prepare the decisions.

As earlier described in deliverable 2.2, decision-making is influenced by a number of factors (e.g. data, administrative structures, spatial scale, duration of project stakeholders etc.). Urban decision-making differs from country to country and is depending on the different domains and levels of decision- making. However, overall the involvement of citizens increases with the shift from urban government to urban governance. The deliverable elaborates this shift as by detailing not only the role of the state employees for example domain experts preparing the decision-making, decision-makers and external experts, but also the citizens and the general public.

The aim of this Deliverable 3.2 of the UrbanDecisionMaker is to provide an overview of the national concept integration, and describe methods, techniques and approaches used to develop a generic reference architecture for the UrbanDecisionMaker. This deliverable begins by describing the modeling approach in section 2, followed by an analysis of the national concepts in section 3 in which we present common features and then derive the core features supporting decision-making. Special attention is given to the cooperation between decision-makers, experts, and citizens. Despite the diversity of the national concepts, a small number of basic concept metaphors emerge. These concept metaphors described in section 4, form the fundamental ingredients for supporting the design of the UrbanDecisionMaker.

D3.2 URBAN DECISION-MAKER

2 MODELING APPROACH

The task of this section is to identify common features found in the national concept that, support different approaches to urban decision-making. Thus common features could be explicitly stated functionalities from the concept applications or implicit functions of the applications e.g supporting the preparation for decision-making or the collaboration processes in the decision-making. Based on the national concepts, each concept is carefully considered to identify which functionality the decision- maker should provide. Based on fieldwork in cooperation with the involved cities, interviews with officials, literature studies and participatory design workshops, a number of national concepts were identified meeting the needs of each cities unique decision-making context. The concepts describe specific visualisations and decision-making, supported by them bring us closer to the concrete domain and context.

This section describes the analysis approach, in which we compare and map the national concepts functionalities. The result of this leads to a model of the UrbanDecisionMaker, represented in the form of a use case diagram and use case descriptions. The similarities in the functionality are in part supported by the similar data sources, such as social media, and visualisations, such as graphs and maps. The purpose of identifying common functionalities and functions there of, is to establish generalised ways of understanding similar functionalities, data, visualisations and design patterns from the concepts while modelling the common units that form the UrbanDecisionMaker.

The design described below is a result of repeated cycles of reading the national concepts, abstracting common terms and functionalities, holding the initial use cases again up against the national concepts. Special attention has been paid to the concepts based on fieldwork on concrete decision practices.

In the following section we proposed modelling notation, in which we describe its origin, design paradigms and constituents. We further describe, how these constituents intend to support the identification of common design challenges, and identification of possible system components.

2.1 Choice of Modeling Notation

The approach to modelling the UrbanDecisionMaker utilises UML standards to understand design patterns and identify common functionalities that can be transformed into clear system structures that define the UrbanDecisionMaker and the interfaces with the UrbanDataVisualiser. UML standards were introduced into software engineering by the Object Management Group (OMG), an international open membership, not-for-profit technology standards consortium. End-users, academic institutions and government agencies drive the improvement of OMG standards. The OMG Task Forces develop

D3.2 URBAN DECISION-MAKER

enterprise integration standards for a wide range of technologies and an even wider range of industries. 1

The OMG specifies that:

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components." 2

Using UML for defining the UrbanDecisionMaker, allows for the integration of different national concepts in a structured way. UML supports an object-oriented approach and promotes a modular and flexible design. Using UML standards such as use case graphical models, activity diagrams and others, helps to manage the increasing complexities that emerge as we build the UrbanDecisionMaker.

 Use Case Diagrams will be used for describing how different actors interact with similar functionalities (Use Case) based on the Scenarios from the national concepts. The Use Cases Diagram defines (e.g similar functionalities, similar potential support-functionalities, similar user) interactions between users and the system that then allows us to define clusters of functionality.

 Use Case Description will be used for further specifying the interaction with the system and will take the form of generic scenarios focussing on the intent of the users and their interactions with a future UrbanDecisionMaker. They are abstracting from the different national concepts.

 Activity Diagrams are used to further refine the activities and the processes involved in the use cases. They define the action of the user as well as specify the functionality of imagined system.

 Component Diagram show different components, available and required interfaces, ports, and relationships between them. This type of diagrams is used to support Component-Based Development (CBD) to describe systems with Service-Oriented Architecture (SOA). 3

 Class Diagrams represents the main blocks of a system and showing its structure as a system by classifying common functional representations as they would be in the real-world e.g

1 http://www.omg.org/gettingstarted/gettingstartedindex.htm 2 http://www.sparxsystems.com/uml-tutorial.html 2 http://www.uml-diagrams.org/component-diagrams.html

D3.2 URBAN DECISION-MAKER

groups of users with certain functionalities in the UrbanDecisionMaker are classified into a single class. The functional representations form the system structure used in a class diagrams.

2.2 Modeling the UrbanDecisionMaker

The presentation of the process described above is oriented towards communicating the design and its rational to the reader.

The results in a use case diagram and related to the use case descriptions. The use case is the context of the UrbanDecisionMaker defined as an abstraction of similar actions and visualisations used for supporting decision-making in the different national concepts. Use case descriptions are based on normal language scenarios. A detailed description of each use case based on the scenarios from the different concepts is given. Where suitable, an activity diagram is drawn up to illustrate the workflows with stepwise activities to show the processes and the decision points. In the context to the modelling this approach adds visibility to an abstract general functionality that forms a concrete unit block of the system.

Use cases provide the basis to define components and there interaction on a high level. The purpose is not to give concrete design architecture but to identify blocks of functionality that the UrbanDecisionMaker needs to support.

In the next section we begin by describing the analysis of the national concepts, in which we first observer the general activities involved in urban decision-making from previous chapter and classify them according to their purpose in the decision-making process, followed by a categorisation of features from the national concept under these classifications.

D3.2 URBAN DECISION-MAKER

3 ANALYSIS OF NATIONAL CONCEPTS

In this section we begin by identifying core features of the national concepts, and classify them according to their position in the decision-making process, for example, when they occur in an evolving decision-making process. The UrbanDecisionMaker is meant to bring urban experts, citizens and professionals into a decision-making process. The elements of decision-making presented in the generic decision-making activities illustrated in deliverable 2.5 figure 8, can be categorised in two groups: Preparing for Decision-Making and Collaborative Decision-Making.

The next sub-section is explaining this distinction. Section 3.2 analyses the national concept and classifies the sub-features them. Section 3.3 then provides an overview mapping the sub-features of the national concepts to decision-making general activities defined in deliverable 2.5 as well as the categorisation developed in 3.1.

3.1 Preparing for Decision-Making and Collaborative Decision-Making

The decision process requires an exchange of knowledge, experience and expertise in order to support the decision-making process. For this reason, features from the national concepts involving several participants are at the core when in supporting Collaborative Decision-Making: Urban experts comment, rate or rank data and visualisation content, elicit public opinions and external expert opinions, and at the same time, they identify and define new issues and additional data requirements.

In order to support Collaborative Decision-making, data representations, analysis, and visualisations defined in the UrbanDataVisualiser must be prepared and arranged both before and during the ongoing expert discussions. Decision-makers and experts must be able to not only view add new visualisations but also share them with others during the decision-making process. To arrange and set up such decision-making environments involves another category of activities that support the process of Preparing for Decision-Making. Based on these preparation activities, experts, decision-makers and citizen then are able to discuss, vote, rate and rank etc. These aspects for supporting collaboration are characterised by a continuous analysis and exchange of opinions and where experts reach a shared consensus. These can be described as ‘monitoring discussions and evaluation’.

D3.2 URBAN DECISION-MAKER

Based on the two categories described above we can relate the defined general activities from deliverable 2.5 as supporting either the preparation for decision-making or the collaborative decision- making. Observe the illustration shown below, showing the generic activities involved in the urban decision-making cycle, as they are categorised, focusing on the core activities highlighted in green and brown to emphasize their appropriation in the UrbanDecisionMaker.

Figure 1: Generic activities in urban decision-making (Deliverable 2.5, p.33)

Functionalities of the identified national concepts can fall in either one of these catgories, with some exceptions falling in both.

3.2 Classifying the Sub-Features of the National Concepts

In this section, we begin by categorising existing features from the national concepts, identifying their support for the preparation for decision-making, and their need for supporting collaborative decision- making. In each case of the national concept the interfacing feature to the UrbanDataVisualiser is the visualisation. In the table below we present the national concepts along with their features and appropriate them according to their support for the preparation for decision-making, collaborative decision-making and interfacing with the UrbanDataVisualiser.

D3.2 URBAN DECISION-MAKER

Table 1 : Mapping national concepts to the classification of decision-making features

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making SE01 Past Incident viewer SE01.1 Collect data generated from social Data gathering from documents media, open data, news media and city and social media government bodies e.g. municipality, fire brigade etc. SE01.2 Users can share documents and image Sharing of data and files Yes files e.g png, pdf, word. etc. SE01.3 Visualise filtered data based on location Shows visualisations of results Yes over a map

SE02 Important Facility Finder SE02.1 Collect data from municipal officials, Data gathering from volunteering police and emergency officials officials SE02.2 Users can export data in tabular form as Export data visualisations as files Yes excel, pdf or word SE02.3 Visualises the search results on a map Shows visualisation of results Yes

SE03 Collaboration Tool SE03.1 Collect data from social media, new Data is gathered from volunteers, media, excel, csv etc. and upload it to social media and news media the open data portal SE03.2 Sharing data as files or as visualisations Sharing data and visualisations & Yes in a collaborative dashboard dashboard SE03.3 Defining dashboards Dashboards Yes

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making SE03.4 Joint discussions on a collaborative Discussions Yes dashboard SE03.5 Show visualisation of data Show data in visualisations Yes SE04 Uploading Data Tool SE04.1 Data is generated by different Data gathering from databases, stakeholder is gathered and stored in a documents & news media central database. websites SE04.2 The uploaded files and information is Sharing information Yes shared with other municipal members using the application. SE04.2 Store collected data Data is stored DK01 Data Book DK01.1 Collect data from public/private agency Data gathering from public and addition of new data to existing data internal sources DK01.2 Browse through existing meta Browse existing data and existing Yes information and data data sources DK01.3 Users can share data, analysis, meta Sharing information and data Yes data, files and data source links with representations other users DK01.4 Visualise map of exiting data sources Visualise network of existing data Yes and data sources DK02 Instagram Map DK02.1 Harvesting instagram images & Data gathering through social hashtags media DK02.2 Save maps with photos & hashtags for Show visualisations for offline Yes further discussions discussions

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making DK02.3 Hot spots showing negative and positive Supports problem identification Yes photos & hashtags DK02.4 Invite planners hold discussions on the Discussions Yes instagram map

DK03 Pattern Movement Map DK03.1 Harvesting GPS data from participating Data gathering through spatial citizens using a mobile App mobile application. DK03.2 Capture and save different movement Show visualisations for offline Yes patterns for discussing with the group. discussions DK03.3 Displays all movement patterns Supports problem identification Yes

DK03.4 Planners hold discussion on the pattern Discussions Yes movement map

DK04 Group Data Workspace DK04.1 Having joint discussions and annotating Discussion Yes visualisations DK04.2 Define collaboration space and invite Define / invite new experts Yes members and experts DK04.3 Show visualisations for offline Sharing visualisations for offline Yes discussions discussion

DK04.4 Define specialized (sub)decision Integrating new decision Yes workspaces for expert working on workspace projects

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making DK04.5 Addition of new data visualisation Inclusion new visualisation to Yes supports decision-making DK04.6 Arrange and compare visualisations for Supports problem identification Yes sense-making on the underlying issues DK04.7 Export it as dashboard Dashboards Yes DK04.8 Visualise multiple visualisations Show visualisations Yes AT01 Trend Monitor AT01.1 Collect data from social media e.g Data gathering through social Facebook, twitter, other media & news media and media sources AT01.2 Define and save social media and media Define re-usable filters for social search filter media and media. AT01.3 Re-use previously defined search filters Searching with filters through social media and media AT01.4 Browse, view and analyze result hits of Show visualisations of results Yes Yes a search AT01.5 Utilizes alerts from AT04 Alerts Yes

AT02 Organization Follower AT02.1 Collect data from different channels e.g Data gathering through social Social media e.g. Facebook, twitter, media and media sources (e.g. other media & news news websites and blogs) AT02.2 Filters are saved, so user does not need Defining reusable filters to select a particular item again, application regenerates the results of the same filter automatically upon opening © 2015 UrbanData2Decide | Urban Europe 15

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making AT02.3 Browse results from different social Browse & choose visualisations Yes media streams in parallel and choose visualisations e.g map, timeline or word cloud etc. AT02.4 Utilizes alerts from AT04 Alerts Yes

AT02.5 Data is visualised in various forms e.g. Visualise of results of existing Yes timeline, maps, word cloud etc. data and their sources

AT04 Alert Sender AT04.1 Data is collected from social media, Data gathering through different blogs, news media and websites social media and media sources (e.g. news websites and blogs) AT04.2 The alert sender is an extension of Integrate new data and Yes other monitoring applications such as visualisation AT01 and AT02 AT04.3 When a threshold is reached, Alert / Notification Yes stakeholders are informed via e-mail, text messages etc. AT04.4 Alert results are visualised graphically Shows visualisation results Yes (charts, timeline) to see how many alerts occurred

AT05 Open Mobility Data Visualiser AT05.1 Citizens and officials add new data Data gathering from citizens and Yes points on the map as well data from the officials open data repositories © 2015 UrbanData2Decide | Urban Europe 16

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making AT05.2 New data is added on maps and Integrating new data and Yes optionally visualised on different forms visualisations of visualisations based on various themes AT05.3 Public can access dashboards showing Dashboards Yes key figures and visualisations AT05.4 Different visualisations display data Show visualisations for offline Yes coming from the open data portal as discussion different layers AT05.5 Data is visualised as maps, graphs, and Show visualisations Yes charts and as attributes (e.g. modal split, number of tags, tags per district, etc.)

AT07 Expert Integrator AT07.1 Prepare collecting data via surveys and Data gathering through surveys/ questionnaires based on structured questionnaire questions AT07.2 Delphi discussions between Discussions between Yes collaborating experts and planners collaborating experts and planners AT07.3 Browsing through argumentation and Integrate new discussions Yes email notifications of new statements features for starting the next discussions. AT07.4 Rating, commenting, ranking of Rating, ranking Yes arguments on whether participants

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making agree or disagree AT07.5 Define and invite experts into a discussion Defining / inviting new experts Yes AT07.7 Shows visualisation of discussion Yes results

AT08 Collective Deliberation Tool AT08.1 Enabling large crowds of citizens to Discussions Yes discuss on societal issues serving as meaningful input for decision-making AT08.2 Exchange of opinion, comments and Sharing information Yes documented knowledge AT08.3 Collecting a user’s decisions and ideas Voting Yes on being in favor of or against issues, ideas and argumentation from the collective. Feed back to officials on the most voted solution. AT08.4 This happens where participants can Rating of discussion Yes revisit arguments and rate them on a scale from 1 to 5 AT08.5 New members from the public can join Defining / inviting new experts Yes in a discussion AT08.4 Visualise discussion results Shows visualisation Yes AT09 Expert pool AT09.1 Add new experts to a database Defining / inviting new experts Yes AT09.2 Problems are identified in AT07 or AT08 Problem identification Yes AT09.3 Select experts from the expert tool and Defining / integrating new expert Yes invite them into AT07 and/or AT08 analyses © 2015 UrbanData2Decide | Urban Europe 18

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making AT09.4 Rank experts and problem from AT07 & Ranking Yes AT08 AT09.5 Export list of ranked experts to PDF, Share files and materials with Yes word etc. and share material with the expert group expert group

AT10 Picture and Video Monitor AT10.1 Images and videos from Instagram and Data gathering from social media YouTube are harvested automatically along with their metadata about hits AT10.2 Municipal officials and stakeholders can Browse & choose visualisations Yes go through a selection of the visual representation of their city or neighbourhood AT10.3 Images and videos are ranked e.g based Ranking Yes on number of likes AT10.4 User can export the result and provide Exporting visualisation Yes direct access to the source AT10.5 The user can see the total number of Show visualisations Yes hits for videos/images, the total number of likes per video/image, and the number of comments per video/image

AT11 Open Data Emergency App AT11.1 Collect data from open data Data gathering from open data repositories and from users repositories

D3.2 URBAN DECISION-MAKER

Concept Features Concept Features Connection to supporting supporting UrbanData Concept Code National Concept Features General Feature Description Preparation for Collaborative Visualiser decision-making decision-making AT11.2 Integrating new user generated data on Integrating new data on Yes different visualisation e.g graphs, maps, visualisations charts, and many more AT11.3 Shows public access to dashboards Dashboards Yes based data from the open data repositories AT11.4 See graphs and charts to visualise Show visualisations Yes attributes of the open data (e.g model split, number of tags, tags per district)

UK01 Social Media Browser UK01.1 Gather data from different social media sources UK01.2 Choose visualisation type for the search Yes results from social media e.g. maps, graphs, word cloud (integrate new visualisations) UK01.3 Visualise results from the social media Shows visualisation Yes filters

UK02 Urban Health Environmental Visualiser UK02.1 Collect data from social media and open Data gathering from public, social data media and open data UK02.2 Choose a visualisations from a pool of Browse & choose visualisations Yes existing set of visualisations

D3.2 URBAN DECISION-MAKER

UK03 Defibrillator Locations UK03.1 Collect data from open data, through Gather data from citizens, health crowd sourcing and existing data about institutions and existing defibrillator locations municipal data UK03.2 Use visualisation to identify problem Show visualisation of existing Yes data

UK04 London Underground Crowding

Indicator UK04.1 Collect data from trackerNet and Gathering data from trackerNet provide it to citizens and open data UK04.2 Not digitalized visualisation Shows visualisation No UK05 Street Lighting Planning UK05.1 Collect data from open data portals Gather data from open data Your about crimes, accidents Environment application

UK05.2 Visualise data on maps to identify areas Show visualisations of results Yes with low level of crime UK06 Your Environment UK06.1 Collect data from open data portals,

D3.2 URBAN DECISION-MAKER

Based on the classification of the each national concept feature we can compare them, identify similarities and derive a general description. Table 2 shows the common features abstracted from common interactions that support decision-making in various decision contexts as defined in the national concepts. We distinguish between features of the national concepts supporting the preparation for decision-making and those supporting collaborative decision-making. Table 2 presents an abstraction of the common features and uniquely allocates them under the two classifications.

Table 2: Common features from the national concepts

Prepare for Decision-Making Collaborative Decision-Making

1. Integrating new data and visualisations 1. Voting 2. Integrating new discussion features 2. Rating

3. Defining/ inviting new experts 3. Ranking 4. Showing visualisation for offline discussion 4. Discussion 5. Sharing visualisation with expert groups 5. Alerts / notifications 6. Exporting visualisation 6. Taking a snapshot 8. Problem identification 9. Defining / integrating interdependencies between analyses 7. Dashboard 10. Share files and materials with expert group 11. Browse through visualisation

3.3 Mapping of Sub-Features from the National Concepts to the General Activities Classified

In this section we begin to map the unique features identified in table 1, section 3.2 to the generic activities, which now form the decision-making features falling under the preparation for decision- making or the collaborative decision-making. Each national concept feature indicated by a code in table 1, can be categories under a decision-making feature and a classification of that feature. Thereby we can group the features that support a functionality of the national concepts. Pattern of common functionalities can then be merged later on.

D3.2 URBAN DECISION-MAKER

Table 3: Mapping of national concepts to generic decision-making activities identified in deliverable 2.5, figure 8

Preparing for Decision Making Collaborative Decision Making

Descion Making n o r d m s ti o t n r e u Features e r a o i v l m p St t so le x te s a t b n e vi s in n rn c o io r n rt a o e e r st o i e r ti lt el P e f d p B u a s fy u e n x & l e d i Q ar a e o t n t p e ss S a a Concepts en e n u lu d r fi c a e n P e is v id I D D E ec D SE01 Past incident viewer SE01.2 SE02 Important facilities finder SE02.2 SE03 Collaboration Tool SE03.2 SE03.4 SE03.3 SE04 Data Uploading Tool SE04.2 DK01 Data Tracker DK01.2,DK01.3 DK02 Instagram Map DK02.3 DK02.2 DK02.4 DK03 Pattern Movement Map DK03.3 DK03.2 DK03.4 DK04 Group Data workspace DK04.6 DK04.3 DK04.4 DK04.5 DK04.2 DK04.1

AT01 Trend Monitor AT01.4 C

AT02 Organization Follower AT02.3 n

AT04 Alert Sender AT04.2 AT04.3 p

AT05 Open Data Visualiser AT05.2 AT05.4 AT05.4 AT05.3 F

AT07 Expert Integrator AT07.3 AT07.5 AT07.2 AT07.3 t

AT07.4 u

r AT08 Collective Deliberation Tool AT08.2 AT08.5 AT08.1 AT08.4 AT08.3 e

AT09 Expert Pool AT09.2 AT09.3 AT09.5 AT09.1 AT09.4 AT10 Pictutures and Video Monitor AT10.2 AT10.4 AT10.3 AT11 Open data Emergency App AT11.2 AT11.3 UK01 Social Media Browser UK01.2 UK02 Urban Health Environment Visualizer UK02.2 UK03 Defiblillator Locations UK04 London Undersground UK05 Street Lighting Planning UK06 Your Environment UK06.4 UK06.2

D3.2 URBAN DECISION MAKER

4 ROLES IN DECISION-MAKING FROM THE NATIONAL CONCEPTS

Based on the interactions between the national concept and the users, the functionalities of these concept features are supported by a number of different roles. Roles can be identified by simple responsibilities, tasks and access to the UrbanDecisionMaker (UDM) functionalities to implement features. Based on the different roles in the interactions with the specific national concepts, generalised roles can be abstracted to support the interactions with the UDM. This indicates that there are different roles in the interaction with the UrbanDecisionMaker. Therefore, users can be categorised according to their roles in the preparation process or collaborative process supporting decision-making. The table below shows grouped scenarios and roles of actors involved in each national concept, supporting the participation process and collaboration for decision-making.

Table 4: Roles of actors in decision-making identified from national concepts

Roles Loc. Concept specific Associated concepts / scenario Preparing Participating in roles visualisations and decision- decision making procedures (Collaborative (Preparation process) process) A. Domain DK Planners Defines search filters, loads Instagram    Experts images & movement patterns over maps, explore & share existing data & visualisations Project Manager Can visualise Instagram images & movement   patterns over maps, define search filters, explore & share existing data SE City of Malmö Can visualise past incidents & important   Officials facilities overs maps, sharing Information, data & dashboard visualisation. Can visualise social media & news media Emergency Visualise past incidents & important facilities  - Officials on maps, sharing Information, data & visualisations through dashboards, can visualise social media & news media UK Health Officials Visualise Social Media data on maps,  

Council officials Browse & visualise social media over maps &   graphs, define search filters AT Planners Monitor discussions & visualise social media   posts, blogs & news media, define search filters, expert discussion & voting City Hall Official Upload, link & visualise case measure data   files, visualise campaign display comments from social media   Police Officials Define & visualise location based search from social media, receive alerts through mobile   Fire Dept. Define & visualise location based search from Officials social media, receive alerts though mobile

D3.2 URBAN DECISION MAKER

Roles Loc. Concept specific Associated concepts / scenario Preparing Participating in roles visualisations and decision- decision making procedures (Collaborative (Preparation process) process)   Public Define & visualise location based search from administrator social media, receive alerts through mobile   Registered citizen Monitor & engage in online crowd based discussions, view visualisations  B. External DK Workshop Analyzing Social Media data over map to Expert Designer understand cultural & social economic maps Social Network  Analyst Analyze or view Social Media over map for cultural infrastructures

AKB - Social View social media maps, and can engage in   Housing Company discussions with planners on infrastructural officials issues

Researchers Can visualise & analyze social media data &  - all existing data, define search filters

SE Police Officials Visualise past incidents & important facilities  on maps, sharing Information, data & visualisations through dashboards. Can visualise social media & news media, upload data files County   Administrative Viewing past incidents & important facilities, Board share information  Emergency Viewing past incidents& important facilities, services view shared dashboards Police services Viewing past incidents& important facilities,  view shared dashboards UK Researchers Browse & visualise and social media over   maps & graphs, define search filters AT Expert Involving external consultants in discussions - Consultation using Delphi methods. Citizens & Public Monitor social media posts, visualise, blogs &   Organizations (e.g news media, define search filters, browse Federal railway, search results public transport organisations) Private Monitor & visualise social media posts, blogs   Organizations ( & news media, define search filters, browse e.g real estate, search results, visualise Campaign Display investors ) comments from social media Researchers Monitor & visualise social media posts, blogs & news media, define search filters D. Decision- DK Citizens View social media maps & other  Makers visualisations Planners View social media maps & other   visualisations

D3.2 URBAN DECISION MAKER

Roles Loc. Concept specific Associated concepts / scenario Preparing Participating in roles visualisations and decision- decision making procedures (Collaborative (Preparation process) process) City of Project manager monitors and reviews   Copenhagen outcomes from the workshops, the municipality approves final plan of the area SE City of Malmö View visualisation of past incidents over  Officials maps, sharing information, data & dashboard visualisation. Can visualise social media & news media AT Municipality View social media maps & other visualisations City Officials Monitor & engage discussion, visualise  expert opinions & voting results UK Policy Makers Browse & view social media on maps &  from local graphs e.g coronoid diagrams, define search Government filters E. General DK Citizen View maps, follow discussions and -  Public participate in data generation through maps SE Citizens - - Generate incidents data, view social media map.

UK Citizens Browse & view data and social media over   maps & graphs, time line maps

AT Citizen Viewing published visualisations &   monitoring ongoing discussions

Based on the concept specific roles identified from the national concepts in table 4 above, we can begin to categorise them into more general description that characterises the tasks and level of interaction that each concept user can perform in their national concept. In this section we describe in detail the generic roles identified in section 3.3 for the UrbanDecisionMaker. Each role represents a possible actor of the UrbanDecisionMaker. Following this section we then begin to look at the basic design metaphors.

Domain expert (organisation intern) These are members of the decision-making organization who are in charge of analyzing data and preparing visualisations for supporting the decision-making process. They initiate the project and establish the project plan and the protocols needed in the collaboration and decision-making process.

External Expert The second role concerns members from outside of the decision-making organization who are invited to be in charge of analyzing some data and preparing some visualisations for supporting

D3.2 URBAN DECISION MAKER

decision-making. Their participation is partial in the preparatory processes for decision-making and they come into a project for short periods of time whenever they are needed. In addition, they also participate in discussions and collaborative activities.

General Public The third important role is that of the members from the general public. These are members who participate in the project by knowingly or unknowingly generating data that influences the decision- making process. These are primarily the owners of a project and can assume any of the other roles depending on their level of involvement in the project.

Decision-Maker The fourth important role identified is that of the decision-makers. These are members on a project, who may not be involved in preparing or analyzing data, but can initiate and engage in discussions, monitor discussions and evaluate alternatives.

5 BASIC DESIGN CONCEPT METAPHORS

The presented basic concepts are very important for building an understanding of the modelling and designing process of the UrbanDecisionMaker. In section 3 we focused on the national concept features and their support in preparing features and visualisations before a decision is made. Whilst most national concepts supported collaborative processes leading to a decision-making, some others supported preparatory processes and visualisations. In this section we distinguish between the aforementioned viewpoints as two building blocks forming the UrbanDecisionMaker and describe the related national concepts falling under them.

Prepare for decision-making The first important basic building block forming the UrbanDecisionMaker concerns a group of features that support the preparation process for decision-making. In the different national concepts, we can identify domain experts who are normally employees of the municipality and who are knowledgeable about the available data. These domain experts already now access structured data sources in the preparation of municipal decisions and applications for financing of projects. They lead participatory decision processes involving external experts, decision-makers and citizens. The UrbanDataVisualiser described in deliverable 3.1 is used to develop visualisations needed to support a decision-making processes. However, decision-makers, domain experts, external experts and the public need to collaborate in a decision-making space to deliberate on a decision. This process requires that the preparation process for decision-making is conducted in the same space.

D3.2 URBAN DECISION MAKER

For this reason, domain experts need to be provided with an interface that allows them to create decision spaces, invite other domain experts and external experts and share visualisations with them. Among other tasks performed in these decision spaces, domain experts and external experts must arrange visualisations to support sense making, create discussion forums both structured and unstructured e.g. to support Delphi processes, and export them as dashboards for decision-makers on the web. The dashboards can then be accessed by citizens and commented on as part of the participation in the decision-making process. The difference between the role of domain experts, external experts, decision-makers and the general public is that domain experts and external expert prepare for the decision-making process, and the decision-maker and general public participate in decision-making. This process of preparing for decision-making can be represented by a menu in the UrbanDecisionMaker, e.g ”prepare for decision-making” under which you will have use cases supporting this process e.g “browse and add visualisation”.

Collaborative decision-making The second basic concept forming the UrbanDecisionMaker concerns the collaborative decision- making process. This concept relates to the process by which members (e.g domain experts, external experts, decision-makers and the general public) of a particular project, work together in a decision space sharing knowledge and opinions through discussion and illustrate different view points based on the visualisations. This concept describes a group of features involving all members on a project in decision-making. Collaborative decision-making features involve the use of visualisations and consensus measuring tools (e.g. voting, survey, ranking). Collaborative features for urban decision-makers must be added to a decision space before a collaborative decision is reached. These features include visualisations, alerts/notifications, and discussions, voting surveys, rankings and ratings. Collaborative features in decision-making are based on numerous visualisations including dashboards snapshots and saved images. The preparation of collaborative decision-making features may fall under the preparation for decision-making process, however, the process itself is a continuous one, and therefore requires a separate menu to support the monitoring of this process.

Visualisation Visualisations are defined as a (pointer) to a data source and a representation of this data. The representation should be in form of a software function so that data updates are rendered immediately in the UrbanDecisionMaker Interface. That means that the visualisation objects have to carry the meta-information necessary to present the data. Deliverable 3.1 defines the kind of visualisation and the functionality to specify them based on open data repositories and results of mining from social network data. The UrbanDecisionMaker focuses on the usage of (blackboxed) visualisations as a base for sense making, cooperative decision preparation, structured discussion

D3.2 URBAN DECISION MAKER

both within an expert team and involving the general public. Understanding visualisations as consisting of a (pointer to) data source or as a data source and a fitting representation provides the possibility to flexibly include additional data and its visualisation into an ongoing decision process. Furthermore, the proposed architecture will also allow for situations where the decision processes themselves results in useful data that can be visualised. The UrbanDecisionMaker will provide decision-makers the possibility to use visualisations from the UrbanDataVisualiser in a decision- making context. This would mean that a common place would be needed for decision-makers to collaborate and make decisions.

Widgets windows These are elements of graphical user interface, which will provide interaction between the UrbanDataVisualiser and the UrbanDecisionMaker. They will display sub-windows of the visualisations and collaborative decision-making.

Decision Space A decision space describes the common environment that is shared by domain experts, external experts, decision-makers and the general public to use in a decision-making context. Such an environment could be a Web 2.0 canvas, used for housing sub-windows (widget windows) presenting visualisations from the UrbanDataVisualiser. The presented visualisations provide a base for discussions and surveys involving citizens, voting and expert involvements. However, in order to support sense making, visualisations need to be arranged in a meaningful way. Not every user will be arranging visualisations or creating discussion forums. Decision-makers for example might just be interested in an update of information and the result of citizen consultations or expert discussions. Several users can be part of one decision space. Activities among group members of a decision space can result in further collaboration in another specific topic spaces depending on the decision approach or decision levels involved. This is particularly significant for groups working with interdisciplinary issues/topics. A user will access more than one decision space and will have rights based on specific roles and responsibilities in the decision process.

Private workspace This is a non-sharable space used by domain expert having administrative rights to manipulate e.g add visualisations; share visualisations with other decision spaces. A private workspace is similar to a decision space, but it is not used in the context of decision-making.

D3.2 URBAN DECISION MAKER

Dashboards A dashboard is a non-editable decision space consisting of several different visualisations. In this decision space data is still updated when visualisations are refreshed. Users can interact with the collaborative decision-making features included in the dashboard. For example, the system will have widgets displaying voting pols, ranking and rating of alternatives, over a dashboard that is subject to analysis.

Snapshot A snapshot is a fixed image (e.g. jpg or pdf) of the current state of a private workspace or decision space for documentation and governmental accountability during an analysis of visualisations. A saved image is a stored representation of visualisations and their content as they are in their original form as certain point in time.

Saved Image If users perform annotations and discussions on the current state of the data and its visualisation, must save a version of the state before it changes. Annotations accompanied by discussions and comments on a state of a data and visualisations carry meaning based on the analysis of visualisations and data at that point in the decision process and the proceeding decision relays on a new version of the data and its visualisations. By saving an image, we preserve the state of the decision for further review and analysis. A saved image is a depiction of what certain visualisations and supporting discussion leading to a decision meant. The decision point remains frozen for future analysis.

D3.2 URBAN DECISION MAKER

6 THE URBANDECISIONMAKER USE CASE

In this section we begin the conceptual design of the interactions and features of the UrbanDecisionMaker. The generic roles identified in section 3, provides the starting point for the different actors. These actors interact with the generalised features described in the national concept analysis in section 3.2 table 1 and table 2, which aggregates the classification. In this section we utilise the components identified from the previous sections to construct a use case diagram showing the core features of the system and its interactions with the actors. Section 6.3 then provides a series of full descriptions of each interaction with the decision-making features based on examples from the national concepts. Subsection 6.4 presents a role analysis class diagram. Finally we provide a table relating the use cases and the national concept.

6.1 Actor Descriptions

Domain expert This is a group of users with full administrative right to the whole UrbanDecisionMaker (mainly organization internal). Their responsibility is to prepare, supervise, monitor, and support decision- making, e.g. urban planners.

External Expert This is a group of users granted administrative access to browsing, adding and sharing visualisations in the preparation process of decision-making. In addition, they have full administrative access to collaborative features such as monitoring, viewing dashboards, voting, ranking and others. Their main interaction will be through collaborative decision-making features. Their responsibilities on the project are based on specific expertise contributions requested by urban project management or team leaders. Groups of participating citizen might act as external experts in part of the decision- making process.

General Public This is a group of users who are not granted administrative privileges. Their basic need is to monitor decision-making processes, and engage in discussions. Such users view dashboards over already prepared decision spaces. When participating in collaborative decision-making, they will need to be provided with log in credentials. These users include citizens, companies, media, and any user without administrative responsibilities participating on the project wishing to share their opinion.

D3.2 URBAN DECISION MAKER

Decision-maker This is a user without administrative rights to the UrbanDecisionMaker. There main role is to monitor data, discussions, and participate in evaluating and establishing decision points in the decision- making process. Decision-makers who engage in discussions could also act as external experts when granted administrative rights. Such users could be politicians, local government officials and council representatives. Decision-makers would not normally prepare for decision-making themselves, unless grated rights to create decision spaces, but can only join decision spaces when invited.

6.2 Actors Use Case

The use case diagram below describes the common functionalities and associated actors from the different concepts. The diagram describes how the features fit in the collaboration and preparation of the decision workspace.

Figure 2 : Urban decision-maker use case diagram

D3.2 URBAN DECISION MAKER

6.3 Use Cases

6.3.1 Create Decision Space A first more basic use case concerns creating a decision space. Decision spaces can be shared with other domain experts, decision-makers, external experts and the public. These spaces are shared environments, used to prepare and support collaboration in decision-making.

Use Case Description

Actors involved Domain experts and external experts have privileges to create decision spaces. These could be planners, municipal officials, emergency officials, and consultants.

Scenario A user wants to create a new municipal decision space for domain and external experts. For example, a team leader of an integrated urban renewal project theme wants his team to collaborate on a number of decisions concerning a specific aspect the project. S/he will create a decision space where planners can work on a specific urban renewal project.

Precondition The user has logged into the system. After log in, the system presents the user with a private workspace and a full menu for gaining access to existing tools.

Use case interaction Once a user enters their private workspace, they can select “New decision space” from the “prepare for decision-making” menu and create a new decision space. The system opens the “create decision space” dialogue screen for specifying details of the new decision space (e.g. name, description and addition of members). After filling in the information, the user presses the “create new decision space” button and an icon representing the new decision space appears on the private workspace.

Post condition The new decision space is now created with a number of initial members. Users with access rights can now share visualisations with the new decision spaces, invite additional members, and add collaborative decision-making features.

D3.2 URBAN DECISION MAKER

6.3.2 Browse and Add Visualisation A second use case concerns browsing and adding visualisations to a workspace. The possibility of browsing and adding visualisations allows users to arrange visualisations in ways that are meaningful for decision-making. Domain experts and external experts must have access privileges to the tools for adding preparing the decision space.

Use Case Description

Actors involved Domain experts and external experts can access multiple decision spaces to browse and add new visualisations to a decision space or a private workspace. These are users with administrative privileges and access to features for preparing decision-making.

Scenario An urban planner wants to add visualisations to a common decision space that is shared among other planners in an urban renewal project.

Precondition The user is logged into the system and navigates to the decision space they want to work with. S/he also has privileges to add visualisations to this decision space. Use case interaction The user navigates to the “prepare for decision-making” menu to open the visualisation browser. Upon selecting the “add visualisation” from this menu, the system displays a dialogue box to browse through a list of icons representing existing visualisations. The user adds a new visualisation to the private workspace or decision space, by scrolling through the browser and selecting an icon from the list, dragging it and dropping it to a decision space. The selected visualisation appears graphically in a widget in the decision space. If a visualisation is not available from the list, a user can create a new visualisations from the UrbanDataVisualiser by pressing the “create new visualisation” button and the current screen switches to the UrbanDataVisualiser. The user defines the new visualisation and switches back to the UrbanDecisionMaker’s interface where he repeats the first steps of adding a visualisation from the “prepare decision space menu”.

Post condition The new visualisations are added to the decision space and other users can view, annotate, arrange, resized, render them.

D3.2 URBAN DECISION MAKER

6.3.3 Add Collaboration Features A further use case concerns the addition of special features that support collaboration in decision- making and can be added to the decision space. Domain experts, external experts and decision- makers will often exchange opinion or reach a consensus by using features such as discussion forums, voting, ranking and rating of alternatives during their collaboration in the decision-making process. These features can be added to a decision space after its creation to support collaboration among members of a decision space.

Use Case Description

Actors involved Domain experts and external experts such as planners, municipal official have administrative rights to add collaboration features to a decision space, like creating discussion forums, creating voting or ranking forms on dashboards etc.

Scenario Users acting as domain experts and external experts want to initiate discussions of visualisation of social media data and fixed data about an area’s social economic status. For example, municipal officials want to create a discussion between external consultants and decision-makers about a problem raised by citizen photos and comments from instagram, on the safety in an area.

Precondition The user is logged into a decision space and has privileged access to the full application menu.

Use case The user selects the “new collaboration feature“ from the “collaborative interaction decision-making” menu. The user chooses what kind of collaboration features s/he wants to add. Depending on the choice future configuration information for dialogue screen appears to specify the topic. A resizable discussion forum widget appears in the decision space with a text field for entering a message and an enter button. Post condition The collaboration feature is created and members can begin to add their argumentations. The user can add other collaboration features into the decision space from the collaborative decision-making menu, and would appear as widgets on the decision space.

D3.2 URBAN DECISION MAKER

6.3.4 Create Dashboard A fourth more complex use case concerns the display of multiple visualisations and collaboration decision-making features as a dashboard. All visualisations come from the UrbanDataVisualiser. Domain expert and external experts must have access rights to visualisations and representations from the UrbanDataVisualiser to create dashboards, where the general public and decision-makers have restricted rights to only view and monitor dashboards.

Use Case Description

Actors involved Domain experts and external experts require administrative access to manipulate visualisations and decision spaces. For example, urban planners, municipal officials, emergency officials and external consultants will need privileges to view, analyze and perform changes on a decision space.

Scenario A user wants to create a dashboard for an urban renewal project theme to describe how traffic noise is affecting people’s social life and movement patterns in a neighborhood. S/he may want to create dashboard visualizing social media, traffic data and citizen movement. Visualisations from different members of his team have to be combined in a decision space to gain deeper insight.

Precondition A user is logged in and has entered a decision space for which he has administrative rights. The decision space contains visualisations and collaborative decision-making features that are arranged in a meaningful way.

Use case The system allows the user to annotate visualisations when preparing to interaction create a dashboard. A user selects “new dashboard” from the “prepare for decision-making“ menu. The system opens a dialogue box to specify the dashboard title and description and upon competition, the decision space is frozen and the dashboard is created.

Post condition A new dashboard is created and can be viewed through a url, and can be used for future discussions among domain experts and external expert members, including members of the general public and decision-makers. The data presented in the visualisations is refreshed every time the dashboard is rendered.

6.3.5 Sharing Visualisations A use case focuses on how users will share visualisation with decision spaces. Sharing of visualisations involves moving visualisations from the private workspace to a decision space. A user creating a particular visualisation is the sole owner of that visualisation in the decision space they share it with, other users cannot delete or edit the shared visualisation unless the owner enables this privilege on it.

D3.2 URBAN DECISION MAKER

Use Case Description

Actors Domain experts and external experts have privileges to move visualisations involved from one decisions space to another. These users could be planners, expert consultants, municipal officials, health officials, emergency officials and other users with administrative rights to manipulate a decision space.

Scenario A user wants to share a number of visualisation s/he has in their private workspace with members of other emergency response departments. For example, an emergency official wants to share visualisations with other departments as they are analyzing a particular crisis situation in a decision space.

Precondition A user is logged into a decision space where he/she has access to all other existing decision spaces including all existing visualisations.

Use case A user logged into specific decision space, accesses visualisations in his/her interaction private workspace. Here the user shares his/her visualisations by moving them from the private workspace to the decision space. Using a drag and drop functionality they place the visualisation over the decision space icon in their private workspace.

Post The new visualisations appear in the shared decision space for others to use. condition The visualisations are now visible to all other members with meta information describing who shared them.

6.3.6 Take a Snapshot The capturing of a snapshot involved generating a fixed still image (e.g jpg, pdf, png) of a decision space as it would be at particular time. This feature allows users to capture historical moments of a decision space without copying the data.

Use Case Description

Actors involved Decision-makers, domain experts, external experts and the general public following a particular project might want to capture an image of the current state of the decision space.

Scenario A user wants to capture a fixed image of the current state of the decision space.

D3.2 URBAN DECISION MAKER

Precondition The user is logged into a decision space and has privileges to view existing visualisation in a decision space, and interacts with the collaboration features.

Use case The user selects the “take a snapshot“ from the “collaborative decision- interaction making” menu. A dialogue screen appears to specify the title, name and format of the image. Then the user specifies the location to save the file and the system creates a new saved image file (e.g jpg, png, pdf) of the current state of the decision space. Post condition The snapshot is created and members can access it for future referencing when building reports.

6.3.7 View Snapshot History A snapshot acts like a fixed photogram of an instance of a dashboard as it looked in the past. Accessing these captured images of decision space instances, allows users to revisit past decision contexts by downloading them and using them in reports and discussions. Snapshots can be thought of as a rich history of different conclusions captured as fixed images to support a final decision outcome.

Use Case Description

Actors involved Decision-makers, domain experts, external experts and the general public following a particular project might want to view old snapshots taken during a collaboration process.

Scenario A user wants to view old snapshots from a decision space. For example, a planner wants to build a report showing systematic changes in the visualisations and needs to access old snapshots of the decision space that were taken at different times of the decision process. S/he wants snapshots from different visualisations to support their claims on what lead to a particular decision.

Precondition The user is logged into a decision space where s/he has privileges to browse and view snapshots in a decision space.

D3.2 URBAN DECISION MAKER

Use case The user selects the “browse snapshot history “ from the “collaborative interaction decision-making” menu. A dialogue screen appears showing a list of image icons of previously saved snapshots for that particular decision space in which s/he is logged into. Then user selects the image file (e.g jpg, png, pdf) with the name and date they wish to view and the snapshot is visualised in a widget where it can be downloaded. The snapshots are ordered along a time land depicts. Post condition The state of the system has not changed.

6.3.8 Engage in Discussions All users having access to the system can engage in discussions about visualisations and comments in the decision space. Members can participate in any discussion on a particular decision space by being members to that decision space. However, the general public may only engage in discussion without having membership, but by simply accessing a URL with visualisation and a forum of an on-going discussion. For example a dashboard accessible to the general public with a discussion forum for comments about the visualised data.

Use Case Description

Actors involved Domain experts and external experts can participate in ongoing discussions forums should express their opinions about certain topics raised from the visualisations. Scenario An external expert wants to contribute some ideas and opinions to an ongoing discussion over a dashboard showing visualisations about 20 000 citizen comments from Facebook about an ongoing construction of a park and a recreation center in an area. For example, historian wants to join in on a discussion between residents and planners in a forum created by the domain expert in our case a project leader. The external expert wishes to discuss about the issues raised about the surrounding areas of a new entertainment center and park in a residential area.

Precondition The user is logged into a decision space and has privileges to read the forum discussions.

Use case The user selects the decision space for which they have membership to interaction and in the selected decision space they click on the text field in the discussion forum widget window. The user then types his/her message into the text field and presses the enter key to upload a message to the forum. The message then appears in the forum display above the text field.

D3.2 URBAN DECISION MAKER

Post condition A forum message has been posted.

6.3.9 Sign up for Alerts Features Alerts are predefined elements of the UrbanDataVisualiser that can be extended to the UrbanDecisionMaker. Moreover, alert can come in different forms but in the UrbanDecisionMaker they are considered as visualisations. Users who need alerts must sign up in the UrbanDecisionMaker and specify the type of alert and the visualisations.

6.3.9.1 Use Case Description

Actors involved Domain experts, External experts, decision-maker such as planners, municipal official need to pay close attention to visualisation and keep track of certain thresholds defined in the UrbanDataVisualiser.

Scenario A user acting as a domain expert wants to get notification of certain amount of negative or positive comments generated from social media about a new construction. For example, a municipal official wants to know how many twitter comments are in support of a newly constructed central train station in an area and would like to receive an alert from the visualisations.

Precondition The user is logged into a decision space. The system has access to alerts defined on visualisations in the UrbanDataVisualiser.

Use case The user selects the “sign-up for alerts“ from the “collaborative decision- interaction making” menu. A dialogue screen appears and the user selects the alert from a list of alerts and specifies his contact information, name, e-mail and cell phone number. Upon completion the alert is then assigned to him/her.

Post condition The alert is assigned to the user. Only a user signed up for an alert receives an alert.

D3.2 URBAN DECISION MAKER

6.3.10 Save Image over Visualisations Social media data frequently changes and other forms of real time data also changes in accordance to the new data coming into the UrbanDataVisualiser. Discussions over a given set and state of visualisations leading to a particular decision must be subject to review and further analysis. Saving an image of the current visualisations and discussions supporting an augmentation is important. This use case is concerned with capturing an image of the current visualisation along with its current data, and supporting discussions and argumentations for future use.

Use Case Description

Actors involved Domain experts, external experts, decision-maker such as planners, municipal official need to pay close attention to the correlation between temporal visualisations and fixed data visualisations.

Scenario A user acting as a domain expert wants to capture visualisations with their data at a specific point in time in a decision process. The user wants to capture a dashboard showing visualisation on social media data and fixed data about an area and the discussion that has lead towards a particular decision. For example, municipal officials discussing with local politicians want to capture a specific point of meaningful analysis about citizen tweets, photos and hash-tags, compared with visualisations from fixed data about drug offences of an area. The user wants a frozen image of the temporal visualisations that are concerned with a discussion that lead to a particular decision.

Precondition The user is logged into a decision space and has privileges to view all visualisation in a decision space.

Use case The user selects the “save image over visualisations“ from the interaction “collaborative decision-making” menu. A dialogue screen appears to specify the title, name of the image. The system creates and saves an image of the existing visualisation and named link with a time stamp of when it was captured appears in a widget listing all saved images.

Post condition An image is created and members a decision space can reference it in future discussions.

D3.2 URBAN DECISION MAKER

6.4 Class Diagram

A class diagram is used to describe the structures and relationships in the interactions between the UrbanDecisionMaker and the different roles of the users, indicating how the different generalised roles of actors are represented and grouped in the UDM system. The class describes the prosperities common to a grouped of specialized classes (sub-classes) e.g the “role” class provides all properties common to “domain expert”, “external expert”, “decision-maker” etc. whereas the sub-classes define their own unique properties to be used by a “workspace user”. This structure represents a blue print in which for instance the “decision space” can represent many different decision spaces used in many other decision contexts. A decision space can also have more than one member (1...*) of a type of role and that member can only be one unique person (workspace user) in the spaces they are working in. Figure 3 below illustrates this modelling of the system.

Figure 3: A Class Diagram of the UrbanDecisionMaker

We identify role patterns in which a single person may have one or more roles in the UrbanDecisionMaker. We model this by generalizing actors, e.g planners, decision-makers, citizens into the person. A person can then be considered to one or more roles e.g external expert, domain expert, decision-maker and general public depending on their responsibilities in a decision space. This structure lets a person change roles dynamically over time. A person my start as a citizen (general public ) participating in a project workshop and then later be involved as an external expert contributing expert knowledge. In this case we would like to establish that a person’s role can change depending on their role in the decision space. These different roles interact with collaborative decision-making features in "CDM features” type of classes of the UrbanDecisionMaker, and where the decisions take place.

D3.2 URBAN DECISION MAKER

6.5 Mapping of National Concepts and Use Cases

Table 5: Mapping of national concept features to the use cases of the UrbanDecisionMaker

Prepare For Decision Making Collaborative Decision Making

Use Cases r fo th s s e i a n y e n vs c e s to e w e e o r h i a s n n c s c c si o t d io r s t p o io i a n a a s is f r s e s e a s o n t s s sp o p p u H o e a s v n rt iv rn n h io za n r k ti s s rd c t t c o cu O io e t e o C t li o e r a r k a is o o a b s e t l a g lt si d a a si b o s o r o D h p h i g a A rn n a i n is u s m li W o b sh s s s D a is e e ti c a l s u e W a W h g p ap k a l v lt a n e a vi c n u r s in a r D in Im a e A R o D e su is M o is e g a r n sn o su ci e s i g D e si V th in D o s W w ge e i e k g t w V in t i o t it a ie a v V R n in Concepts a o g vi c re n r n w e V g a a tt e r n n e a a o o ie k n S R o r B a I D h xp V a E V C rr S E M T A SE01 Past incident viewer SE01.2 Yes Yes Yes SE02 Important facilities finder SE02.2 Yes Yes Yes SE03 Collaboration Tool SE03.2 SE03.3 Yes Yes Yes SE03.4 SE03.2 SE04 Data Uploading Tool SE04.2 DK01 Data Tracker DK01.2 DK01.2 DK02 Instagram Map DK02.4 Yes Yes Yes Yes DK02.4 DK02.2 DK03 Pattern Movement Map DK03.4 Yes Yes Yes Yes DK03.3 DK03.2 DK04 Group Data workspace DK04.4 DK04.5 DK04.6 DK04.2 DK04.3 DK04.7 Yes Yes Yes Yes DK04.1 DK04.3 AT01 Trend Monitor AT01.4 Yes Yes Yes Yes AT01.5 AT02.3/AT0 AT02 Organization Follower AT02.4 2.4 Yes Yes Yes Yes AT04 Alert Sender AT04.2 Yes AT04.3 National AT05 Open Data Visualiser AT05.2 AT05.3 AT05.3 Yes Yes Yes Yes AT05.4 Concepts AT07 Expert Integrator AT07.3 Yes Yes Yes Yes AT07.2 AT07.4 AT07.4 AT08 Collective Deliberation Tool AT08.2 Yes Yes Yes Yes AT08.1 AT08.4 AT08.3 AT09.1/AT0 AT09 Expert Pool AT09.2 AT09.6 AT09.5 9.3 Yes Yes Yes Yes AT10 Pictutures and Video Monitor AT10.2 AT10.4 Yes Yes Yes Yes AT10.3 AT11 Open data Emergency App AT11.2 AT11.3 Yes Yes Yes Yes UK01 Social Media Browser UK01.2 Yes Yes Yes Yes UK02 Urban Health Environment Visualizer UK02.2 Yes Yes Yes Yes UK03 Defibrillator Locations Yes Yes UK04 London Underground Crowding indicator Yes Yes UK05 Street Lighting and Planning Yes Yes Yes UK06 Your Environment UK06.3 Yes Yes Yes Yes UK06.2

D3.2 URBAN DECISION MAKER

7 EXISTING TECHNOLOGIES

A number of existing technologies offer some of the explored features of the UrbanDecisionMaker. Their implementation can be scaled and would require some configuration and /or customization to be able to support the identified features from the UrbanDecisionMaker. Technical implementation of customization would depend on basic standard models e.g model view controller (MVC), and prescribed technical documentation of the respective framework e.g Ckan document manual for customisation.

7.1 Content Management Systems

Content management systems are applications that allow publishing, editing and modifying content, organizing, deleting as well as maintaining provided features from a central interface. We consider content management systems as suitable implementations that support a common environment where decision-makers can collaborate and make decision. The features of these applications support the UDM features. This section gives an overview of different available content management systems for the use in web application projects. Again the programming language in which they are written groups the systems.

Table 6: List of existing content management systems

Site Name Description OpenCms is a JSP Servlet container such as Apache Tomcat[4] . It is a CMS application with a browser-based work environment, http://www.openc asset management, user management, workflow management, OpenCMS

ms.org/en/ a WYSIWYG editor, internationalization support, content versioning, and many more features including proxying of requests to another endpoint.[2] DotNetNuke OsComerce Joomla4 was initially released in 2005. The current version of http://www.joomla Joomla! the system is 3.2.3. On their website they state that the system .org/ was downloaded over 35 million times. Drupal5 was first released in 2001. The latest version is 7.26.

https://drupal.org/ Drupal According to their website more than one million sites worldwide use Drupal.

6 http://magento.co Magento is an E-Commerce platform and was first released in Magento

m/ 2008. The current version is 1.8.1.0. According to their website

4 http://www.joomla.org/ 5 https://drupal.org/

D3.2 URBAN DECISION MAKER

Site Name Description more than 200.000 merchants use this system.

Typo3 7 was first released in 1998. The current version is 6.2. https://typo3.org/t According to their website the system was downloaded more Typo3

ypo3-cms/ than 8 million times and more than 500.000 websites use this CMS. Pimcore8 is a content management system written with the Zend Framework. The current version is 2.0.2. According to their website more than 65.000 websites use Pimcore. Due to https://www.pimc Pimcore the fact that it is based on the Zend Framework, it is easy to ore.org develop own features for the system. Critics say that it is hard to use out of the box and that an understanding of the Zend Framework is necessary.

7.2 Web Development Frameworks

The following sections present different frameworks which are the current state of the art for the development of web applications. In order to structure this overview more clearly the frameworks are grouped according to their programming language.

7.2.1 PHP This section presents different web application frameworks for the programming language PHP. Most of the following frameworks are designed according to the Model-View-Controller9 (MVC) pattern which helps to structure the code of the application and therefore follows the principle of Separation of Concerns10 (SoP).

7.2.2 Yii The Yii Framework11 is written in PHP and it was founded by Qiang Xue in 2008. Before starting the Yii project Qiang Xue developed Prado12, another PHP framework. The acronym “Yii” stands for “Yes it is” and presents the answer to the question if the framework is the right choice for a new web development project. The current version of the framework is 1.1.14. Yii 2 is available in 2014 and it

6 http://magento.com/ 7 http://typo3.org/ 8 https://www.pimcore.org/ 9 http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller 10 http://en.wikipedia.org/wiki/Separation_of_concerns 11 http://www.yiiframework.com/ 12 http://www.pradosoft.com/

D3.2 URBAN DECISION MAKER

is a complete rewrite of the current version of the framework. The new version requires PHP 5.4 and embraces best practices and protocols of modern web applications. As many other frameworks Yii implements the MVC pattern. The following figures illustrates a typical workflow within a Yii application and presents the interaction between the model, the view and the controller.

Figure 3: Typical workflow in a Yii application13

On the website of the framework features of Yii are listed. These features are presented in the table below.

Table 7: Features of the Yii environment

Feature Name Description By providing various useful database functionalities which ease the Data Access Objects (DAO), interaction with the persistence layer of the application, Yii decreases Query Builder, Active the troubles of writing plain SQL statements and increases the security Record, DB Migration of the application. With the availability of a set of validators and numerous helper Form input and validation methods the task of validating form input is simplified.

13 http://www.yiiframework.com/doc/guide/1.1/en/basics.mvc

D3.2 URBAN DECISION MAKER

Feature Name Description Through the direct integration of jQuery into the Yii framework, it is possible to create versatile user interfaces easily. Additionally Yii AJAX-enabled widgets provides various AJAX-enabled widgets, e.g. data grid or autocomplete form input fields which support fast web development. Authentication and Yii has an integrated role based access control system which allows authorization developers to manage the rights of users in a convenient way. The use of themes enables developers to completely change the Skinning and theming appearance of the website with almost no effort. The automatic generation of WSDL service specifications is supported Web services by Yii. Furthermore Yii helps with the management of web service requests. Concerning internationalization and localization Yii supports message Internationalization (I18N) translation, date and time formatting, number formatting and interface and localization (L10N) localization Yii offers the opportunity to use different caching methods and Layered caching scheme furthermore the storage medium can be chosen and changed easily. Error handling is directly supported by the framework and additionally Error handling and logging log messages can be categorized, filtered and routed to different locations. Yii features various security measures which help to avoid attacks like

Security SQL injection, cross-site scripting (XSS) and cross-site request forgery. Unit and functionality Unit testing is supported by the framework. Additionally functional testing testing based on PHPUnit[1] and Selenium[2] is possible. Through the availability of different code generations tools automated Automatic code code generation is possible, which helps with the generation of trivial generation code like CRUD operations. Friendly with third-party It is easy to use third-party code like sources from PEAR[3].

code Every used method or property in the framework is documented. Detailed documentation Additionally books and tutorials help with the development. With the existence of an extension library consisting of user-

Extension library contributed components the features of the framework increase further

7.2.3 Zend The Zend14 Framework uses the programming language PHP and it was initially released in 2006. The current version of the framework is 2.2.5. Since version 2.0 it is referred to as Zend Framework 2

D3.2 URBAN DECISION MAKER

(ZF2) and since then it is written in a complete object-oriented way. The framework features a component structure, which makes it possible to solely use components to enrich existing PHP applications or to combine those components to a high performance MVC implementation. The component structure is a difference to other PHP frameworks which, as mentioned in the introduction to PHP frameworks in general, mostly directly follow the MVC pattern.

Table 8: Features of the Zend Framework 2

Feature Name Description Through the mentioned focus on a component-based structure the framework is Component-based loosely coupled, which means that it is easy to use only parts of the framework for different PHP projects.

In contrast to the first version of the framework, ZF2 now supports autoloading. This Autoloading feature helps to get rid of the various require_once statements needed in ZF1.

ZF2 supports testing of the web application via automated testing and Testing continuous integration. In order to achieve that it makes us of PHPUnit and Travis CI16.

7.2.4 Symfony Symfony17 is a PHP framework and it was first released in 2005. The current version is 2.4.2. Since the release of version 2 it is referred to as Synfony2. Similar to the Zend Framework Symfony2 features a component-based structure. Due to this approach it is possible to use individual components separately. Nevertheless in combination Symfony2 provides a full-stacked web development framework. Each of the components is available via a dedicated GIT repository.

Table 8: The following list18 shows the available components

Feature Name Description

DependencyInjection, EventDispatcher, HttpFoundation, DomCrawler , ClassLoader , Component-based CssSelector ,HttpKernel BrowserKit Templating Translation ,Serializer ,Validator, Security ,Routing Console ,Process ,Config ,Finder, Locale, Yaml , Form.

14 http://framework.zend.com/ 15 https://travis-ci.org/

17 http://symfony.com/ 18 http://fabien.potencier.org/article/49/what-is-symfony2

D3.2 URBAN DECISION MAKER

7.2.5 Laravel The Laravel19 framework is written in PHP and was first released in 2012. The current version is 4.1.18. In a survey about the most promising PHP frameworks in 2014, Laravel was listed as the most promising framework20.

7.2.5.1 Model View Controller (MVC) Laravel implements the MVC design pattern. The following figure illustrates this concept within Laravel.

Figure 4: MVC with the Laravel framework21

Table 9: Features of the Laravel Framework

Feature Name Description Laravel uses composer22 to manage its dependencies. Therefore it is very Composer easy to use third-party sources in the project. The Eloquent ORM is a simple Active Record implementation which is directly Eloquent ORM built into Laravel. With the help of Eloquent it is easy to work with different kinds of databases within the web project. Templating is made easy within Laravel. On the one hand developers can use native PHP for the creation of templates for the website and on the other hand Templating developers can use the integrated Blade template engine which decreases the overhead of the creation of templates.

19 http://laravel.com/ 20 http://www.sitepoint.com/best-php-frameworks-2014/ 21 http://laravelbook.com/laravel-architecture/

22 https://getcomposer.org/

D3.2 URBAN DECISION MAKER

Feature Name Description Community With an IRC chat room and a forum, problems can be addressed easily. Laravel is built on top of several Symfony components, which helps to make the Proven Foundation young framework more mature. Testing Laravel supports the use of PHPUnit for testing purposes.

7.2.6 Phalcon Phalcon23 is a web framework written in C and published as a PHP extension. It was initially released in 2012. The current version is 1.2.6.

7.2.6.1 MVC As many other web frameworks it features the well-known MVC design pattern. Following the principle of separation of concerns, it is a good fit for web applications.

7.2.6.2 Performance Probably the biggest upside of this framework is the high performance which comes with the fact that Phalcon is written in C and therefore the performance can be increased compared to other frameworks directly written in PHP. Additionally it is very resource friendly. A downside of using C as programming language is that for the installation of the framework root access to the server is needed which not all server providers support.

The figure below compares the performance of Phalcon to other PHP frameworks. Besides the frameworks CodeIgniter, Laravel and Zend, which are discussed in this document, this comparison also takes the PHP framework Kohana24 into account. With approximately 2500 requests per second Phalcon features the highest performance compared to the other frameworks.

23 http://phalconphp.com/en/ 24 http://kohanaframework.org/

D3.2 URBAN DECISION MAKER

Figure 5: Comparison of performance of PHP frameworks

7.2.7 CakePHP CakePHP25 is a PHP framework initially released in 2005. The current version is 2.4.6. It implements the MVC design pattern and features code generation as well as scaffolding. Configuration is made easy and due to built-in security features for input-validation, CSFR protection, form tampering protection, SQL injection and XSS prevention, developers are able to write secure applications.

7.2.8 CodeIgniter CodeIgniter26 is written in PHP and was first released in 2006. The latest version, 2.1.4, was released in July 2013. Around the same time the current owner of the framework announced that they are seeking a new owner for the framework.

Due to the fact that it is / was one of the most used respectively popular PHP frameworks there are a lot of websites written with CodeIgniter. Nevertheless as time passed other frameworks adapted to newer design patterns and best practices in software development. Still, CodeIgniter is a very good starting point for newcomers in the area of web development with PHP.

25 http://cakephp.org/ 26 http://ellislab.com/codeigniter

D3.2 URBAN DECISION MAKER

7.2.9 Comparison of PHP Frameworks PHP as a programming language has a pretty bad reputation in general. This is reasoned with the fact that it is very easy to start programming with this language and therefore many people without real development skills began to write PHP code, which lead to a lot of insecure and faulty software. Additionally concepts like object orientated programming were not possible prior to PHP5. In order to decrease the development time and to use a well-tested foundation for web applications, developers should make use of frameworks in the development.

In the above sections different PHP frameworks got presented. Most of those frameworks follow the popular MVC design pattern which is based on the concept of separation of concerns and therefore they are a good fit for the development of web applications. In the following those frameworks get compared directly with each other.

Zend Framework 2 and Symfony2 implement a more component based structure. This loosely coupled approach makes it possible to use individual components for different web projects. Using the components altogether developers can also implement the MVC pattern with those frameworks.

Regarding the programming language, Phalcon takes a unique approach since it is completely written in C. Therefore the code must be compiled and is then used as a PHP extension. This strategy brings on the one hand an increase in the performance but on the other hand requires root access to the server since the framework must be installed via a PHP extension.

The decision which framework is the best is not easy to make. It highly depends on the requirements of the project. As mentioned, CodeIgniter provides an easy point of access to PHP frameworks in general. If performance is an issue then Phalcon should be considered. Zend Framework 2 and Symfony2 are considered as enterprise frameworks which are a good fit for big software projects since they provide a lot of functionality. The increased functionality although brings a high learning curve for those frameworks.

The decision whether a framework is a good choice or not also depends on the state of the development of the framework. Newer frameworks like Laravel make use of current state of the art programming principles and therefore they should be considered as very interesting. As presented in the section about Laravel, this framework was ranked as the most promising framework for 2014. Although the result is only based on a small survey and therefore the result of the survey may be questionable, it functions as an indicator for the direction web application programming with PHP is heading. Fehler! Verweisquelle konnte nicht gefunden werden. shows the result of the survey. As pointed out, the first place goes to Laravel. Due to its unique approach and its high performance Phalcon is considered as the second most promising framework for 2014. The third place goes to Symfony2 and the fourth place is a tie between CodeIgniter and Yii.

D3.2 URBAN DECISION MAKER

Figure 6: Most promising PHP frameworks for 2014

The figure above presents a Google Trend Analysis about the above noted 5 most promising PHP frameworks for 2014. The analysis shows a bit different result. In this case CodeIgniter is on top of the list, which can be reasoned with the fact that this framework still has a very huge community. On the second place is Yii which has received very positive feedback over the last few years. With the upcoming release of version 2 this framework will become even more interesting. The third place in this ranking goes to Laravel closely followed by Symfony. Phalcon lands on the fifth place.

D3.2 URBAN DECISION MAKER

Figure 7: Google Trend Analysis of popular PHP frameworks

7.3 JavaScript Frameworks

This section presents different web application frameworks written in JavaScript. Such frameworks are primarily used for single-page applications (SPA) like Facebook. In order to provide a rich user experience and an increased performance, the interaction with the website is handled on the client- side. In most of the cases the communication with the server is accomplished via AJAX calls to a REST-api of the application. The clear abstraction of the server- and the client-side brings the possibility to implement the REST-api in different programming languages.

7.3.1 AngularJS AngularJS27 is a frontend framework written in JavaScript. It was initially released in 2009 and is now maintained by Google. The current version is 1.2.3. On their website they state the following about the framework:

“AngularJS is a structural framework for dynamic web apps. It lets you use HTML as your template language and lets you extend HTML's syntax to express your application's components clearly and

27 http://angularjs.org/

D3.2 URBAN DECISION MAKER

succinctly. Angular's data binding and dependency injection eliminate much of the code you currently have to write. And it all happens within the browser, making it an ideal partner with any server technology.”

In essence Angular targets the problem that HTML was not designed for dynamic web views but rather for the presentation of static content. Therefore Angular adds features to HTML in order to make it possible to develop dynamic applications completely on the client-side.

7.3.2 Backbone Backbone28 was initially released in 2010 and the current version is 1.1.0. It is very lightweight since it only depends on one JavaScript library. On their website they state the following:

“Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.”

Since it solely depends on one JavaScript file, Backbone is considered more as a library than a framework. Therefore the developer has more freedom in the development regarding the architecture of the application. This can be seen as advantage and disadvantage, since it gives the developer more flexibility, but also makes it possible to write unstructured not well-written code.

7.3.3 Ember Ember29 is a JavaScript framework initially released in 2011. The current version is 1.5.0. On the GitHub page of the framework they state:

“Ember.js is a JavaScript framework that does all of the heavy lifting that you'd normally have to do by hand. There are tasks that are common to every web app; Ember.js does those things for you, so you can focus on building killer features and UI.”

The framework is very powerful, but the learning curve is also quite high. The framework provides a clear structure for the code which a developer is expected to follow.

7.3.4 Comparison of JavaScript Frameworks Fehler! Verweisquelle konnte nicht gefunden werden. illustrates a Google Trend Analysis about the presented JavaScript Frameworks. As illustrated, AngularJS has received by far the most attention in recent years. On GitHub, AngularJS is the sixth most starred repository available30.

28 http://backbonejs.org/ 29 http://emberjs.com/

D3.2 URBAN DECISION MAKER

Figure 8: Google Trend Analysis of popular JavaScript frameworks

8 CONCLUSION

The purpose of the deliverable is the analysis of the design of the UrbanDecisionMaker, based on the national concepts provided in the deliverable 2.5. To this end the national concepts are analysed, and common features are identified and the concept specific actors are categorised based on the role they play in the decision-making process.

The features are categorised into two groups, preparing for decision-making and collaborative decision-making. Based on this analysis central design components and a use case diagram together with use case description have been developed. A class diagram is used to clarify the relationships among the central concepts. The last section provides an overview over contents management systems and the technical frameworks that can be used to implement the UrbanDecisionMaker. Together with the deliverable 3.3 this analysis and design provides the basics for the UrbanData2Decide framework in the deliverable 3.4.

30 https://github.com/search?q=stars%3a%3E1&s=stars&type=Repositories

D3.2 URBAN DECISION MAKER

REFERENCES

Mathaissen. L, Munk-Madsen. A, Axel Nielsen.P., 2000. Object Oriented Analysis and Design, Vol 1, No.1.

ABBREVIATIONS

UDM: UrbanDecisionMaker

CDM: Collaborative Decision-making