Projects and Studio: Why Geobble Has Two Working Surfaces

A geographic workflow rarely demands the same kind of attention from beginning to end.

At first, the difficult part may be deciding what the question actually means. Which Sources are relevant? Does “nearby” mean straight-line distance, travel time, or administrative proximity? Should the result compare places, identify exceptions, or produce a map for a particular audience? The work is exploratory because the user is still discovering the shape of the problem.

Later, the difficulty changes. The question may be settled, the useful layers may already exist, and the remaining work may depend on precision: which features should be visible at each scale, how the classes should be presented, where labels belong, what a popup should reveal, or how several editors should refine the same map without losing one another’s changes.

These are parts of one workflow, but they are not the same activity. One benefits from conversation, context, and the ability to request a result in terms of an objective. The other benefits from direct manipulation, stable controls, and immediate access to the structure of the map.

Geobble has two working surfaces because forcing both activities into one interface would make each of them weaker.

A Project is the surface for developing a geographic answer. Studio is the surface for working directly on the map and its data. They remain connected because the output of exploration often needs production craft, while production work often raises questions that send the user back into exploration.

The Difference Is Not Beginner Versus Expert

It would be easy to describe Projects as the simple interface and Studio as the advanced one. That distinction would be convenient, but it would also misunderstand why both exist.

Experts ask exploratory questions. They compare possible methods, inspect unfamiliar Sources, test assumptions, and use provisional maps to understand what deserves further attention. A conversational surface can be valuable in that work because the user can express an objective without first translating every part of it into a sequence of interface operations.

Beginners also need direct control. Once a map exists, they may know exactly what feels wrong: a label appears too early, an important layer is hidden, the legend is unclear, or the initial view does not show the intended place. Rephrasing the whole request to an assistant can be less natural than selecting the relevant element and changing it directly.

The distinction is therefore not based on who the user is. It is based on what the user is doing at that moment.

Projects are useful when the work is organised around a question. Studio is useful when the work is organised around an object that the user can inspect and edit. The same person may move between those modes several times while producing one map.

A Project Begins With Intent

A traditional GIS interface usually begins by presenting tools, panels, files, layers, and an empty or partially configured map. The user is expected to know which operation should come next.

A Project begins from the opposite direction. It gives the geographic objective a place to remain visible while the user brings Sources, Maps, Collections, and other context together around it.

The user might ask which settlements fall outside a thirty-minute service area, how two boundary revisions affect a comparison, where several environmental conditions overlap, or what an effective public map of the result might look like. Those requests contain analytical and cartographic intent, but they do not necessarily specify every intermediate operation.

Within a Project, the assistant can help inspect available data, compare places, resolve locations, perform spatial or mobility analysis, create derived results, assemble layers, and develop a first map. It can also work with the current geographic view, so phrases such as “in this area” or “what am I looking at?” can participate in the conversation rather than being treated as incomplete instructions.

This does not mean that the assistant should make the workflow opaque. The value of the Project surface is not that it hides every operation, but that it allows the user to reason at the level of the question while the system helps translate that intent into inspectable work.

A Project is therefore more than a chat attached to a map. The conversation, context, derived Sources, analytical choices, and current map develop together.

Studio Begins With the Map in Front of You

Once the work has a visible form, the user’s attention often becomes more specific.

The question is no longer only whether population should be compared with access. It becomes whether the access layer should sit above or below the settlements, whether the colour progression communicates increasing difficulty, whether labels remain readable at the city scale, or whether a popup exposes the information a reader will actually need.

Studio is designed for this closer relationship with the map.

Layers can be selected, reordered, grouped, styled, filtered, labelled, hidden, duplicated, or limited to meaningful zoom ranges. Legends, popups, the default view, and other map settings can be refined directly. Annotations and drawing tools can support the production process, while collaborative state allows several people to work on the same map and reconcile changes rather than passing separate copies between them.

Studio also includes data-oriented work where direct review matters, including feature extraction and Source enrichment. The common principle is that the user is not only describing an outcome; they are examining the elements of the work and deciding what should happen to them.

This is why Studio is not simply a larger version of the Project interface. Its purpose is not to expose every capability in one place, but to make the structure of the map available for deliberate editing.

Why Conversation Alone Is Not Enough

A conversational interface is powerful when the desired result is easier to describe than the path required to create it. “Compare accessibility under walking and driving conditions” is a meaningful request even when the user does not know which services, transformations, or visual layers will be needed.

Conversation becomes less efficient when the user is already looking at the exact thing they want to change.

A request such as “make the second layer slightly less prominent, move it beneath the boundaries, show its labels only after the regional view, and keep the current popup fields except for the internal identifier” can be expressed in language, but the language is now reconstructing information that the interface already knows. The user has selected a layer, can see its position, and may understand the desired change through immediate visual feedback.

Direct manipulation shortens that loop. The user changes the map, sees the consequence, and adjusts again without having to turn every perception into a complete verbal instruction.

There is also a question of confidence. When refining a final composition, users often need to know exactly what changed and what did not. Explicit controls make local edits easier to understand, compare, undo, and coordinate with collaborators.

A system that insists on conversation for every edit risks turning the assistant into a remote control for an interface the user should be allowed to touch.

Why One Large Editor Is Not Enough Either

The opposite design has its own limitations.

A sufficiently large editor can expose every available operation through menus, panels, dialogs, and toolbars. In theory, the user can perform the complete workflow without leaving the interface. In practice, the growing number of capabilities makes the user responsible for translating a geographic objective into the product’s internal organisation.

To answer a question, the user first has to know which data to inspect, which operation to run, what parameters it requires, how its result should be represented, and where each control is located. The interface may be powerful while remaining silent about how those pieces should be combined.

This is especially difficult when the question is provisional. The user may not yet know whether a buffer, route, join, aggregation, or comparison is the right method. They may need to ask what is possible before they can decide what to construct.

Projects reduce that translation burden by allowing intent and context to guide the workflow. Instead of requiring the user to begin with the name of a tool, the surface can begin with the problem.

Studio preserves the editor because not every meaningful decision should be converted into a request. Projects preserve the conversation because not every meaningful question should be converted into a toolbar sequence.

The Handoff Should Not Be an Export

Many products divide exploration and production by treating them as separate applications. The analytical tool produces a file, and the design tool imports it. The first environment retains the reasoning, while the second receives only the result.

That handoff creates a familiar loss of context.

The production editor may know what the layers contain without knowing why they were created. A derived dataset may arrive without the assumptions that shaped it. A later analytical revision may require another export, another import, and a manual attempt to preserve the styling already applied. The map gradually separates from the question that produced it.

Geobble’s two surfaces are designed around a different relationship. Projects and Studio operate over the same canonical Map rather than exchanging a flattened output.

When a user opens Project work in Studio, the map does not become a screenshot or a disconnected copy. Its Sources, layers, analysis results, and existing behaviour remain part of the work. Studio can then refine the fields that belong to direct production—such as styling, labels, visibility, groups, legends, basic popups, and view—without erasing the richer interactions or server-backed decisions created elsewhere.

The implementation enforces that boundary when Studio saves. It begins from the canonical Map and merges the parts Studio owns, preserving the parts owned by the Project workflow. The technical mechanism matters because it supports a simple product promise: moving into direct editing should not quietly destroy capabilities that are not visible in the current panel.

The surfaces are separate, but the Map is not fragmented between them.

Boundaries Can Preserve Meaning

Dividing responsibilities between surfaces may initially seem restrictive. A user might reasonably ask why every Project capability is not available in Studio, or why every direct editing control is not reproduced inside the Project conversation.

Some overlap is useful, and both surfaces can assist with map creation and spatial work. Yet complete duplication would make the distinction difficult to understand and the shared Map harder to protect.

Geobble therefore gives each surface a centre of gravity.

Projects own the parts of the Map that are closely tied to server-side analysis, generated context, and richer behaviour: computed information, search, relationships between Sources, camera responses, and advanced popup actions. Studio owns the fields most naturally shaped through direct editing: visual appearance, labels, legends, visibility, groups, map settings, and the current view.

These are implementation boundaries, but they also express a design principle. The surface that understands how a capability was created should remain responsible for its authoritative structure, while another surface may preserve and render it without accidentally rewriting it.

Clear ownership makes movement safer. The user can refine the map in Studio without fearing that the next save will remove an analytical interaction, and the Project can continue developing the work without treating Studio’s visual decisions as disposable decoration.

Collaboration Changes the Kind of Interface Required

Exploration can be collaborative through discussion, shared context, and the review of results. Production collaboration introduces a more immediate problem: several people may edit the same object at nearly the same time.

Studio is built around that reality. Its local document state can reconcile concurrent changes with the canonical project rather than assuming that one person’s saved copy must replace another’s. Annotations can remain part of the collaborative editing environment even when they are not part of the published Map itself.

This matters because map refinement is often distributed across roles. One person may understand the data, another the local geography, another the visual design, and another the communication requirements of the intended audience. Their contributions are not always best expressed as a sequence of prompts to one agent. They may need to inspect the same layers, leave marks, change different parts of the composition, and recover gracefully when their work overlaps.

The existence of Studio acknowledges that map production is not only a dialogue between a user and an assistant. It can also be a shared craft practised around a common object.

Movement Between the Surfaces Should Follow the Work

A user does not need to complete a Project before opening Studio, and Studio is not merely the final polishing stage.

Some workflows begin directly in Studio because the user already has suitable Sources and a clear map objective. They may need to organise layers, prepare data, draw annotations, or refine an existing composition without first asking an analytical question.

Other workflows remain mostly inside a Project because the purpose is exploratory. The user may compare scenarios, create derived Sources, and inspect provisional maps without needing a publication-ready composition.

Many workflows move back and forth. A user may develop an accessibility analysis in a Project, refine its visual hierarchy in Studio, notice that an important group of settlements has been excluded, return to the Project to investigate the gap, and then continue production with the revised result.

The correct surface is therefore not determined by a fixed stage number. It is determined by the next decision the user needs to make.

When the difficulty is expressing or resolving the geographic question, Project is usually the better surface. When the difficulty is directly shaping, inspecting, or coordinating the Map, Studio is usually the better surface.

Two Surfaces, One Geographic Workflow

Software often pursues simplicity by trying to make one interface universal. Every capability is placed into the same environment so that the product can claim there is only one way to work.

That kind of simplicity can become a burden when the interface has to serve incompatible modes of attention.

Exploration needs room for ambiguity, context, alternatives, and provisional results. Production needs precision, visibility, stable structure, and direct control. Treating one as a lesser version of the other weakens both.

Geobble’s approach is to keep the surfaces distinct while preserving the continuity of the work between them. A Project helps the user move from a geographic objective toward an initial answer. Studio helps the user turn that answer into a map whose structure, expression, and presentation can withstand closer attention.

The user should not have to choose between the intelligence of a conversational workflow and the control of a direct editor. The useful question is which form of interaction the work needs now; and whether the Map can remain intact when that need changes.