This section discloses the findings we obtained from the literature review and user interviews and presents the conceptualization of an interactive PSS tool for a maptable, narrowing down the many specific aspects to what is required in practice by users.
4.1. A Maptable: Potential Shortcomings and Requirements of Maptable Software Applications
Based on the literature, concerning: a) case studies where a maptable was applied; b) general shortcomings of the available PSS tools, i.e., software applications for this instrument; c) potential requirements; and d) our own experiences of maptable-based PSS workshops, we found the following.
Different studies in diverse sectors of applications emphasize the potential of a maptable to support collaborative spatial planning, for instance, to enhance the communication among different types of stakeholders, e.g., expert and non-expert, and offering analytical functionality to generate better-informed plans or proposals. The majority of the studies concerned strategic urban planning issues [42
], followed by planning studies related to climate [15
] and environmental health [17
]. We also found applications in the energy sector [18
], and transportation [29
]. In several of those studies, scholars reported that the enhanced interaction provided by a maptable might lead towards knowledge sharing, knowledge combination, or consensus-building [46
Although a maptable has shown potential as demonstrated by the case studies, the authors also encountered some limitations. For example, it can accommodate only a limited number of people and can be intimidating for elderly or low digital literate stakeholders [18
]. Case studies also reported shortcomings of software applications, i.e., the digital tool implemented in a maptable, when delivering spatial content. This aspect is the focus of our research. The issues that were identified concerning software applications for a maptable are summarized as follows:
Single root: GIS desktop applications do not fully exploit the touch capabilities because they have single-user roots, i.e., they were designed for a single user, i.e., one user at the time [32
Expert systems: conventional tools are developed for and by experts that can handle sophisticated technologies which may limit the participation of non-expert stakeholders [4
Turn-taking: Turn-taking is a regular implementation of the collaborative group work, i.e., stakeholders use the software in turns, but the software itself is not aware of this and does not keep a record of those turns [49
]. Hence, individual contributions cannot be traced.
Software offer: the offer of mature and stable GI-based software specially designed for supporting large touch devices and collaborative group work is scarce. Besides, the current offer does not satisfy the needs of most users [8
Open source software: open-source software tools that allow for collaborative development of extensible applications are scarce [7
In addition to the general software shortcomings mentioned above, we also listed the desired capabilities of a planning support tool as envisioned by researchers. We categorized those capabilities, also known as potential requirements as follows:
Concerning navigation, scholars documented the need for mobile-oriented designed applications. This means apps with intuitive GUI (Graphical User Interface) adapted to an interactive surface, i.e., simple and minimal menus using larger buttons, and gesture-based user interaction [50
Capabilities for data input concerned advanced editing, namely: automatic closing of shapes, easy drawing of regular forms; copying, pasting, resizing, and rotate features; freehand drawing and annotation; adding markers or comments and typing via a virtual keyboard [43
Potential requirements related to data management address information reuse and integration; for example, the integration of information via databases, map libraries and multiple sketching layers. Besides, import and export of parameters values, results or maps is desired [45
With regard to spatial analysis, scholars reported scenario planning, timely evaluation of alternatives via indicators, embedded GIS functionality and cost-benefit analysis as pivotal functions expected in a PSS tool [12
In terms of visualization, scholars remarked the importance of a balance in the data used to limit the cognitive effort of stakeholders, e.g., by limiting the number of concurrent layers being displayed, showing a reduced number of indicators at once, and providing different visualization forms understandable for a wider audience, e.g., dashboards, linked visualizations of maps, charts, and graphs and efficient rendering of large datasets [12
]. In addition, intuitive and interactive styling and advanced visualization such as 3D views were listed as needed for supporting planning processes [18
Other relevant qualities for a PSS as understood by researchers refer to a) the performance of the tool, e.g., handling large datasets or cloud computing; b) the learning curve, i.e., guidance through workflows, well-structured help; and c) adaptable and understandable models [12
In summary, based on the potential requirements and shortcomings found in the literature and our previous experience in attending and moderating planning workshops, we identified four dimensions to structure our interviews, namely:
the principal spatial analysis of a maptable PSS tool,
the must-have functionalities of a maptable PSS tool,
tracking of individual contributions and,
space-time settings for group work collaboration.
Dimensions a and b were chosen to stress the core of requirements that would enable users to achieve their intended tasks when applying the tool being conceptualized, i.e., the principal spatial analysis that is required and the minimum essential set of functions for a map-based PSS tool. Dimensions c and d were selected on the basis of our experience gathered during attending and moderating previous maptable-based PSS workshops, e.g., the limited window in space and time that people have to participate in a workshop and the lack of support in discriminating individual contributions. Besides, these dimensions imply functionalities that are not regularly included in a PSS tool, because they go beyond the standard or base level of performance of a GI-based tool.
4.2. User Stories Derived from the Interviews
In the following sections, we analyze the responses of the identified user groups structured by the identified requirements from Section 4.1
, namely a) principal spatial analysis, b) must-have functionalities, c) tracking of individual contributions, and d) space-time settings for group work collaboration. For each dimension, exemplifying user stories are given, following the template presented in Box 1
. For readability, we refer to our intended users in a general way, e.g., researchers instead of interviewed researchers. Also, when we refer to statements made by a specific respondent we identified her/him as follow: Pi
represents a planning practitioner (i
ranges from 1 to 2), Rj
refers to a researcher (j
ranges from 1 to 4), Gk
refers to a GIS expert (k
ranges from 1 to 3), and Lm
states for a layperson, with m
ranging from 1 to 2.
a) Principal Spatial Analysis
We found that the majority of case studies as reported by our respondents applied a maptable during an exploratory phase (intelligence), i.e., for gaining an understanding of the planning problem or issue at hand. In those cases, map visualization and essential input data functions, e.g., adding markers, were sufficient for the intended purpose. In other instances, impact evaluation via indicators was the principal spatial analysis used in planning workshops giving stakeholders immediate feedback on specific intervention proposals. Table 1
lists the responses of our interviewees, followed by examples of extracted user stories related to this topic.
Example of user stories:
As a planning practitioner, I want to integrate different layers so that I can quickly identify ideal locations for certain facilities.
As a researcher, I want to have a scenario analysis combined with impact analysis of alternatives so that I can see the effect of specific measures on the problem being tackled.
b) Must-have functionalities
In this dimension, interviewed users responded at different levels of details providing statements that were classified as non-functional and functional requirements. The non-functional requirements, also known as quality attributes, describe how the tools should be whereas the functional requirements refer to specific capabilities, e.g., calculations, input type, etc., desired for the new tool under construction. We listed below a summary of the must-have capabilities according to our interviewees, the first set of qualities are rather generic, whereas the following are specific:
Customizable: a tool adjustable to the context and topic under discussion.
Transparent: the user can know and modify any assumption of the tool.
Interoperable: meaning easy integration with common GIS applications and formats, and portability of the resulting analysis.
More intuitive interface: the UI of the new tool looks and works similarly to a tablet or mobile phone, e.g., simple interfaces with bigger buttons.
Web-based: the app is available online.
OS: the app is Open Source.
Reliable: recovers from failures with minimum data loss.
Complexity: the complexity of the tool according to the tackled phase of planning and the specific intended stakeholder participating in a workshop mediated by a maptable.
Modularity: the application allows for a progressive addition of functions as the planning process advance.
Data collection: adding markers to the map concerning the issue at stake.
Sketching and adding notes: free-hand drawing and adding text notes on the map canvas.
Impact assessment: provides immediate feedback on the effects on predefined indicators of sketched interventions being discussed.
Scenario analysis: constructs and analyses future conditions concerning the problem at stake.
(user-driven) Spatial Multi-criteria Evaluation (SMCE): stakeholders can perform a multi-criteria evaluation and tune its parameters.
3D views: visualization of tri-dimensional data.
Examples of user stories:
As a researcher, I want to have a GUI rich in pictures so that people with low education (e.g., unable to read) can easily use the application.
As a GIS expert, I want an application available on the web so that more people can participate remotely and integrate the result of that interaction into the discussion mediated by a maptable.
As a Researcher, I want an open-source application comparable to current private touch-oriented apps for a maptable so that users can have a satisfactory experience without the restrictions of private software.
As a layperson, I want to have an app that does not freeze so that participants remain engaged/active in the discussion.
As a Planning practitioner, I want to quickly draw in a few steps so that the process of proposing interventions can be faster.
As a Planning practitioner, I want to sketch on the maptable using free-hand gestures so that I can express ideas or concepts as I normally do during design discussions.
c) Tracking of Individual Contributions
Common applications for maptable-based PSS tools do not offer the capability for keeping track of individual contributions. We explored to what extent our intended users do need to discriminate individual inputs during a planning workshop where a maptable is used. Table 2
presents gathered responses in this matter, in which we observe that more than half of our participants judged tracking individual contributions of stakeholders as not important or slightly important.
Example of user stories:
As a researcher, I want to track individual inputs so that I can understand how stakeholders become more concrete across the planning session or whether changes in the proposal can be related to a communicational process (e.g., learning).
As a planning practitioner, I want to be able to discriminate individual interventions of participants so that I can understand who proposed a particular intervention during the planning workshop.
d) Space–Time Settings for Group Work Collaboration
In general, in the geospatial community, there is an increasing interest in supporting multi-user collaboration in different space-time settings, particularly in asynchronous distributed environments [56
]. In this dimension, we enquired our users’ perspective concerning how useful it would be having extended capabilities to accommodate interactions among stakeholders in distributed–asynchronous and distributed–synchronous settings (see Figure 2
). This feature goes beyond the current support offered by a maptable in a co-located–synchronous setting that is typical of face-to-face planning workshops. Responses collected are listed in Table 3
In general, respondents considered the support for the distributed-synchronous setting not important or slightly important. However, some respondents envisioned potential uses cases that may require this kind of configuration, for example, in a professional environment where users remotely need to co-design proposals, and it is not possible to timely meet in face-to-face. Additional insights emerged concerning this issue. We listed those below:
As participants or stakeholders, being located in different places, work on the same problem perhaps in different geographic contexts, a competitive rather than collaborative behavior may be triggered (L1). Hence, there is a potential risk of a group dominating the discussion (R2, G1). Besides, stakeholders need to feel comfortable with the applied technology, i.e., a maptable and the software application to effectively participate in a discussion (L1).
The group dynamic occurring in a particular space can be disturbed by the communication with another group. Hence, there is a risk of diverting the discussion from the planning problem at stake by focusing on the interaction with the other group (G1).
The logistic effort required to configure such a system to support distributed-synchronous setting would be quite complex and perhaps might not add significant value to the planning process. Besides, the benefits of applying a maptable rely on the face-to-face interaction among stakeholders that would be impeded by the increased complexity to synchronize inputs from remote and local groups (R1).
Communication among different groups working on a maptable, e.g., two parallel workshops could be useful for sharing results that each group achieved separately, discussing them and perhaps building a consensual outcome (G3).
Respondents reacted—to some extent—positively on the question of supporting distributed asynchronous settings in combination with a maptable-based workshop. Thus, although practitioners did not find this quality as relevant, more than a third of our interviewees recognized this aspect as moderately important. Use cases for this setting concerned data collection processes, e.g., collecting user preferences or knowledge relating to a specific planning issue via annotated maps, online survey, etc. Respondents provided their perspective on this issue as summarized below:
Often, the workshop participants, i.e., stakeholders, want to know people preferences on the problem under discussion. However, those processes should not be synchronized (R1, G3). Instead, it is useful to have those preferences elicited prior to the workshop, e.g., via online surveys, geo-questionnaires or similar techniques and incorporate them as an input for the discussion (R2, G1).
A potential use case of a distributed and asynchronous setting including a maptable is a variation of the think-pair-share approach (G2) where users have their device, e.g., mobile phone or tablet for data collection or design proposals and their inputs are shared in a next group session. Then, the discussion on a maptable can take the input collected from individual participants or pairs into account (P1, G2).
People contributing to a data collection process that served as input for a maptable session should be able to know about the overall result of the data collection process, e.g., aggregated responses, and the outcome that stakeholder achieved using that elicited data (G1).
Example of user stories:
As a GIS expert, I want to have seamless integration between mobile data collection and the application in a maptable so that I can use the data collected in the field during a planning workshop without much effort.
As a researcher, I want to collect people’s preferences beforehand so that those preferences can be used during a workshop session.
4.3. An Interactive Tool for a Maptable: A Conceptualization from User Stories
In the previous section, we elaborated collected responses with respect to the selected dimensions namely a) the principal spatial analysis, b) the must-have functionalities, c) tracking of individual contributions, and d) space-time settings for group work collaboration. Besides, we provided examples of user stories extracted from those responses. Here, building on the results for the selected dimensions and taking into account that there exists a difference between what can be technically supported and what users need [7
], we present the main building blocks of the digital maptable tool (i.e., a software application) to support a PSS workshop in a planning process, illustrated in Figure 4
. The envisioned tool has three central components offering support concerning mapping, analysis, and space-time settings (see Figure 2
). The mapping support
component contains three subcomponents, namely interactive map, data input and layer management. The interactive map provides a visual workspace where stakeholders can explore geographic information, i.e., geographic layers, through gesture navigation tools such as pinch, pan, rotate, etc. The data input element enables stakeholders to input data, i.e., attributes or characteristics related to a particular location represented in one or more layers that are handled by the layer management. Layers are usually offered by loading local files or consuming geoservices. Through the mapping support component, participants can explore geographic information such as plan interventions, create sketches, or submit data linked to a location via marker or pin. The interaction provided by the mapping support component is compared to an annotated map as it accommodates preferences collection, data input or local knowledge elicitation.
The analysis component (analytical support
) concerns evidence-based methods to tackle the problem at hand. We distinguish two sets of analytical functions. The first set refers to standard features expected for most of our intended users. Compiled user stories indicate that users mainly need SMCE, scenario development, impact assessment via indicators and sketching. These analytical functions, including their output visualization, e.g., an indicator chart, can be applied to produce better-informed plans or decisions [44
]. The second set of analytical functions includes advanced functionality that is specific to the problem at stake and the purpose for which a maptable will be applied. In this way, the application contains a set of common functions that most users require but allows for extension through the advanced and problem-based functions to be developed in close collaboration with stakeholders of the application, i.e., following an HCD approach. The space-time support
component provides functions to accommodate participation in two different space-time settings: co-located synchronous and distributed asynchronous since compiled user stories confirmed some application cases for these settings (see the previous section). For co-located and synchronous settings, the conceptualized tool enables participation via gesture support, i.e., pinch, pan, minimal use of regular mouse and keyboard and a mobile-oriented GUI design, e.g., bigger buttons and simple interface. For distributed and asynchronous settings, the tool provides easy integration with GI-based open source tools for mobile data collection. The three building blocks of the tool aim to support the social interaction (synchronous and asynchronous) among stakeholders and the analysis required to support collaborative spatial planning.