Workflow explorations for the hybrid ITC atlas

: This contribution is about workflows for a hybrid atlas. The atlas maps the history and contemporary activities of ITC (Faculty of Geoinformation Science and Earth Observation, University of Twente). ITC’s mission is capacity development to empower individuals, organizations, and society. By using geoinformation and earth observation, ITC aims to surmount today’s complex global challenges and to contribute to sustainable, fair, and digital societies. The atlas will be published on multiple mediums: digitally as an online edition and analog as a printed edition. We call this a hybrid atlas. As such, it is nothing new: besides regular online, or printed atlases, practitioners often derive an interactive version of a printed atlas, e.g., the “Atlas of Switzerland” in Richard (2000). Also, a great number of exclusively digital atlases, mostly online atlases, have been designed and described in literature (MacEachren et al., 2008, Preuschmann et al., 2017). The hybrid atlas, in contrast, is meant to consider both a digital and analog edition from the beginning. In such an atlas, the two editions are considered not complementary but combined. We identified two major challenges originating from the atlas’ hybrid nature: visual coherence between both editions, and an efficient single-source-publishing workflow for keeping both updated. First, we need link both visually: maps and atlases of communication. the map user and the reading context matters. The product needs to reflect the user needs and context. the needs and contexts for the digital and the analog atlas diverge, switch one the other. the visualizations a common "look and feel" for quick orientation.

This contribution is about workflows for a hybrid atlas. The atlas maps the history and contemporary activities of ITC (Faculty of Geoinformation Science and Earth Observation, University of Twente). ITC's mission is capacity development to empower individuals, organizations, and society. By using geoinformation and earth observation, ITC aims to surmount today's complex global challenges and to contribute to sustainable, fair, and digital societies. The atlas will be published on multiple mediums: digitally as an online edition and analog as a printed edition. We call this a hybrid atlas.
As such, it is nothing new: besides regular online, or printed atlases, practitioners often derive an interactive version of a printed atlas, e.g., the "Atlas of Switzerland" in Richard (2000). Also, a great number of exclusively digital atlases, mostly online atlases, have been designed and described in literature (MacEachren et al., 2008, Preuschmann et al., 2017. The hybrid atlas, in contrast, is meant to consider both a digital and analog edition from the beginning. In such an atlas, the two editions are considered not complementary but combined.
We identified two major challenges originating from the atlas' hybrid nature: visual coherence between both editions, and an efficient single-source-publishing workflow for keeping both updated.
First, we need to link both editions visually: maps and atlases are tools of communication. Therefore, the map user and the reading context matters. The product needs to reflect the user needs and context. While the needs and contexts for the digital and the analog atlas diverge, users may switch from one to the other. Hence, the visualizations need a common "look and feel" for quick orientation.
Secondly, we need to implement an efficient workflow to create visualizations for both editions. This workflow is beneficial even though we may print the atlas only once: it promotes a "release early, release often"-approach for the print edition. Furthermore, it allows user tests at preliminary stages for both editions. We aim to base the workflow on free and open-source software, to make the atlas as reproducible as possible. To address the challenge of a coherent design across editions, we envision a component library (cf. Figure 1). The term component is used in the context of design systems, mainly for web design, e.g. Frost (2016). In our case, a component is a building brick for the atlas. Components can be nested, up to a complex system of "atoms, molecules, organisms, templates, and pages" (Frost, 2016). Adding to the hierarchy, we differentiate three types of components regarding their application: generic, adaptive, and targeted. Most components are generic. They occur across both editions -we consider the print layout as just another (static) interface with different constraints and possibilities than the interactive web interface. Components directly related to the map, like proportional symbols, scales, or legends, are examples for this type. The second, smaller group contains adaptive components. While using the same "atoms" or "molecules" on both editions, they need to adapt slightly based on the medium. One example for such components are map annotations. Requirements for annotations differ depending on the medium they are used in (e.g., to avoid visual clutter caused by static annotations). Thirdly, the smallest group contains targeted components, intended for one specific medium and highly tailored to it. Components of this group are e.g., interactive elements (like input sliders or select elements) for the online layout, or a page footer for the print layout. Visual and structural coherence across nested components is ensured by reusing components and by relying on shared styles (e.g., colors, color palettes, typography, patterns, stroke styles).

Map design
In the past, comparable research-originated solutions focused on components for analytical and data transformation tasks (e.g., GeoVA Toolkit, GeoViz Toolkit, GeoVISTA Studio, and CommonGIS). Today's solutions (e.g., CARTO, Tableau, flourish) add visual components, from which cartographers can choose to create visualizations. These solutions meet requirements for on-screen-use, i.e., components adapt to display resolution and size. Nevertheless, none of the mentioned products aim to provide visual components targeted to multiple channels and respective requirements: e.g., adapting color, resolution, layout when deriving static from interactive visualizations. Therefore, we research how to provide a flexible visual component library.
For an efficient production workflow, we propose a project setup which involves data management, map design, and to some extent publishing. To make multi-source and inhomogeneous data accessible, we plan to implement a basic API (Application Programming Interface). This API enables a uniform access point to these data. We aggregate data so that when accessed through the API, privacy regulations of partly sensitive data are met. The data received from the API is the single source for data-driven visualizations. We plan to create the visualizations entirely with JavaScript. Forgoing GUIs (Graphical User Interfaces) contributes to a reproducible workflow. The aforementioned component library and the API are already partly implemented for the prototypes. They will be expanded during the setup and design phase.
At the center of the single-source-publishing workflow is the SVG-file format. The xml-based "Scalable Vector Graphics" format enables visualizations with interaction possibilities in the browser as well as static print-ready visuals. Nevertheless, we do not limit the atlas visualizations to the SVG format: 3D or visually complex visualizations can be rendered to the HTML canvas-object. Popular and well-maintained libraries for these tasks are, among others, D3 and ThreeJs.
For the online edition, we aim to employ a JavaScript framework, e.g., the react-based framework next.js. We use it to compile the individual components, maps, and supplementary content (e.g., explanatory text, photos, videos) to web pages. For the analog publication, we still explore how to compile the pages. Programmable (i.e, non-GUI) open-source solutions (like L A T E X or bookdown) might impose too many compromises on the atlas design. Common workflows relying on desktop-publishing software like Adobe InDesign or Affinity Publisher are neither open-source nor easily reproducible. Hence, we need to examine further possibilities on how to compile visualizations and the supplementary content into a print-ready PDF document.
Another open questions is to which extent we want such an automated workflow. One example is visual clutter on static visualizations: whereas the user can select, hide or mute irrelevant information in an interactive visualization, this is impossible in its static counterpart. This shows that different mediums can necessitate different visualization techniques. Such workflows also constrain artistic freedom: e.g., breaking out of the design grid is difficult within such generic workflows. Entirely automated workflows may therefore be neither feasible nor desirable. Thus, we need to explore a reasonable extent of automatization.