How should the ribbon be organised? A look at what's there today

[deniial00]

Hi everyone,

The ribbon has grown a lot since it was reorganised by task in #99, so I went through it: every tab, group and dropdown, what each control opens, and where things repeat. Before anything changes, I'd like to hear from you: how you use the ribbon, where you got lost, and what you'd miss if it moved. There are no wrong answers. A short story like "I spent ten minutes looking for X" is just as useful as a full proposal, and so is "please don't touch Y, I use it every day".

What's there today

• Size: about 290 controls sit directly on the ribbon, plus about 30 more while a layout is open. Since Reorganise the ribbon by task: Home, Data, Style, Edit, Analyze, View, Publish #99, 79 commits have changed the ribbon, adding about two dozen buttons and 47 menu entries, including the Web Data menu with 33 services.
• Repeats: 27 commands or panes can be reached from more than one place. The Tools pane has a button on three tabs, 8 buttons on the Edit tab open the Editing pane, and 5 on Data open the Data Design pane.
• Width: Analyze (49 controls) and View (53) are wider than a typical laptop screen, so part of each tab is behind the scroll arrows.
• Inconsistencies: one tool has two names ("Bounding Geometry" and "Convex Hull"), one setting has two toggles ("Lighting" and "Enable Lighting"), and Go To XY and Locate open the same dialog.

Tell us about your experience

Anything you'd like to share helps, for example:

• a tool you couldn't find, or found only through Command Search;
• a workflow that takes too many clicks or tab switches;
• buttons you use every day, and buttons you've never touched;
• something that confused you as a new user, or that you got used to and now like;
• how you work in other GIS software, and what you miss or don't miss from it.

Screenshots and short screen recordings are very welcome.

Questions to think about

1. What belongs in each tab?

#99 describes the tabs as following the order of the work: Home, Data, Style, Edit, Analyze, View, Publish.

• Does that order match how you work?
• How would you describe each tab's purpose in one sentence?
• Style and Data change their content with the layer selected in Layers, and are nearly empty when none is. Does that feel natural, or would you prefer fixed tabs, or tabs that appear only when a layer is selected (as in ArcGIS Pro)?

2. Which actions need a ribbon button at all?

• What could live in a pane, a dropdown, the right-click menu or Command Search instead?
• Is a repeated button helpful (a shortcut where you need it) or confusing (which one is the right one)?

3. Should we have rules for the ribbon?

I drafted a rule book to start from (linked below). Some of the questions it tries to answer:

• Should button size follow how often something is used?
• When is a split button (a fixed main action plus an arrow with variants, like Select since Add polygon, lasso, and radius map selection #855) better than a plain dropdown or separate buttons? Should the main action stay fixed, or switch to the last one used, as in ArcGIS Pro and QGIS?
• Should one pane be openable from several tabs? Should View › Windows be the place for every pane?
• Where do preferences go: on the working tabs, or in Settings?
• Should every tab fit a laptop screen without scrolling, or only its everyday controls?
• What should a new feature's pull request say about where its button goes?

4. How do we get there?

• Rework the ribbon tab by tab in small pull requests, or in one go?
• Which tab first?

How others do it

ArcGIS Pro uses tabs that appear with a selection, galleries, and a published rule that frequent controls are large. QGIS uses menus, toolbars and the Processing Toolbox, and has an experimental Ribbon Toolbar plugin. Both comparisons are linked below.

Material

Everything is in the experiment folder of my fork:

• Full audit: every tab, group and dropdown, what each opens, usage estimates, repeats
• Draft rule book
• How ArcGIS Pro does it
• How QGIS (and its Ribbon Toolbar plugin) does it
• One possible layout, with a prototype on the same branch you can build and click through, and screenshots. To be honest, I don't like it: it removes most duplicates and about 90 controls, and when I clicked through it, some things felt worse. Panes were harder to reach, and familiar buttons had moved. That's a big part of why I'd rather work this out together than just send a pull request. Feedback on what works and what doesn't is welcome.

[giswqs]

@deniial00 Thank you for looking into this.

Let's reorganize the Ribbon tabs one at a time.

Starting with the Home tab.

Here is what I propose: removing those items highlighted in red rectangles. Move Zoom Box to the location of Go To XY.

@opengeos/rustgis-maintainers What do you guys think?

[Mavrick-F]

I'd start by agreeing on a one-sentence purpose for each tab before going tab by tab, so we don't keep moving functions between tabs or relitigating them. Otherwise I agree with @giswqs's Home tab proposal.

On @deniial00's proposal: I think it doesn't quite land because it counts controls instead of starting from tasks. One way to check a layout is to pick a handful of everyday workflows (add data, select by location, buffer, symbolise, export a map) and count the clicks and tab switches each takes. Fewer controls only helps if those numbers don't go up.

A few specific thoughts:

• One button per destination, not per pane. A button that opens a pane at its own section is a shortcut, not a duplicate. Merge only buttons that land in the same place, like Locate and Go To XY.
• Keep View › Windows complete. List every pane there, and let each tab repeat the panes it needs. I suspect the Panes ▾ menu is why panes felt harder to reach.
• Keep modes with their tools. Dark Mode belongs in Settings, but measurement units should stay with Measure, because you choose them while measuring.
• Show which layer Style and Data act on. A layer dropdown at the left of each tab ("Styling: Countries ▾") would make the context clear and fill the empty state.
• Ship the clear fixes now. Locate/Go To XY, the two Lighting toggles and the two names for Convex Hull could go in one small PR while we discuss the rest.

[deniial00]

@Mavrick-F I agree with starting from a purpose for each tab, and your point about tasks over control counts is exactly where my prototype went wrong. Here's a few additions to your list (which I really like!):

• The tab sentence decides where new features go. A PR that adds a button names the tab and explains how it fits that tab's purpose.
• One name per thing. A command has the same label and icon everywhere it appears: ribbon, panes and Command Search.
• A split button only with a clear default. The main action is what people want most of the time and stays fixed. Without an obvious default, use a plain dropdown.

Additionally here's a first proposal for purposes for each ribbon-tab:

• Home: Quick access to the actions used most often, including shortcuts to important commands from other tabs.
• Data: Working with the content and structure of data: looking at records, changing fields and values, connecting tables, and bringing data in and out.
• Style: Deciding how a layer looks on the map: how its features are drawn, labelled and shown at different scales.
• Edit: Creating and changing features and graphics on the map, and managing those edits.
• Analyze: Turning existing data into new results, from single tools to repeatable workflows, scripts and automation.
• View: How the map and the workspace are displayed: the map's appearance and navigation, and which panes and windows are open.
• Publish: Getting work out to others, whether printed, as files, as layouts and reports, or shared on the web.
• Plugins: Finding, installing and using plugins that extend RustGIS.
• Settings: Preferences that apply to every project, such as language, appearance and start-up.
• Help: Learning RustGIS, finding commands and shortcuts, and getting information about the app.

Feel free to make adjustments.

@giswqs I agree with your Home proposal, with two additions in the Add group:

• Add Data as a split button. The main button opens the file picker for all formats right away (what the small Add Data in the Project group does today). The arrow opens the current Add Data dropdown with URLs, services, databases, sample data and so on, plus Add Folder. That way the one-click file picker isn't lost when the Project group goes.
• A small Data Sources button next to it, opening the Data Sources pane with saved connections, favourites, recent data and the library. It's a copy of View › Windows › Data Sources, but people have had trouble finding that pane ([Feature]: CONNECTION MANAGER #641, [Feature]: Connection manager for databases and web services #699). In return, the "Connections…" entry can leave the Add Data dropdown, since it opens the same pane.

What do you think?

[jgregoriorincon]

Thanks for the audit, @deniial00. I agree with going tab by tab, starting from each tab's purpose and checking real workflows as @Mavrick-F suggests. Here is the label side (#858).

Style doesn't fit, and labels are close to half of it. With a feature layer selected, Style scrolls on my screen (screenshots). The five label groups take about 40% of its width: Labels, Label Range, Label Placement, Label Class and Text Symbol. Without them, the rest of Style fits with room to spare. What's still to come for labels will grow exactly that part: halo colour and width, offsets, priority and expressions (#77).

Labels are also split across two tabs. Style has those five groups. View › Labeling has Label, Lock, Pause, View Unplaced and Convert. The Label button (labels.enable) is on both tabs.

Proposal: a fixed Labeling tab, right after Style.

• Purpose: "How the map is labelled: what gets a label, with which text, where, and at which scales, plus the label settings for the whole map."
• Fixed, not contextual. I know Reorganise the ribbon by task: Home, Data, Style, Edit, Analyze, View, Publish #99 removed the contextual tabs so the tab strip doesn't change with the selected layer, and this keeps that. Labeling is always there, like Style and Data. With no layer selected, it shows the same hint Style shows today, next to the map-wide settings, which work without a layer.
• Groups follow the order of the topic tabs planned for the Labeling pane in [Feature]: One place per label setting: the ribbon edits the chosen class, the Labeling pane by topic #858 (Class, Symbol, Position, Range), so the ribbon and the pane read the same way:
  a. Labels: Label (on/off) · Properties (opens the pane)
  b. Label Class: Class · Field
  c. Text Symbol: Size · Color · Bold · Halo
  d. Label Placement: Placement
  e. Label Range: Out Beyond / In Beyond · Closest / Farthest · Clear Limits
  f. Map Labeling: Lock · Pause · View Unplaced (map-wide)
  g. Convert: the layer's labels to annotation
• What changes elsewhere:
  • Style loses its five label groups and fits.
  • View loses its Labeling group, and with it the duplicate Label button.
  • View › Windows › Labeling and the layer's right-click menu still open the pane, as shortcuts from their own context.
• Command ids stay the same. As in Reorganise the ribbon by task: Home, Data, Style, Edit, Analyze, View, Publish #99, the CLI, shortcuts and scripts keep working. Saved tab names map through current_tab.

On "Styling: Countries ▾": since #863, the ribbon has a class chooser and edits the same class as the pane. A layer chooser at the left of Style and Labeling would complete it: first the layer, then its class.

This is self-contained and doesn't depend on the Home decisions. When we agree and the discussion gets there, I'm happy to send it as one small PR and fold it into #858's remaining steps.

[Mavrick-F]

Thanks both. Pulling this together:

Tab purposes. @deniial00's sentences look close. Let's tighten up two of them to reduce ambiguity:

• Home: "The basics of working with a map: starting a map or layout, adding data, moving around, and selecting and inspecting features." Every new feature can claim "used most often", and navigation currently overlaps View.
• Data / Publish: Data exports data (features, rasters); Publish exports products (maps, layouts, reports, packages).

Anything from the controls audit that fits two tabs, or none, needs a fix.

Home, checked that way. With @giswqs's removals, almost everything fits. Three things to settle:

• Directions is analysis (routing), so it moves to Analyze.
• Infographics is a live summary of what's in view. It fits Data better, and a name like "Summary in View" would say what it does.
• Go To XY / Locate: both are circled. I'd keep Go To XY: both open the same coordinates-only dialog, and next to Find Place, "Locate" suggests it searches addresses (as it does in ArcGIS). Later, merging Find Place and Go To XY into one Locate box that accepts either would earn the name.

+1 to Add Data as a split button and to the Data Sources button; #641 and #699 show people didn't find that pane.

Labeling. +1 to @jgregorioincon's fixed Labeling tab; it's well argued and fits this approach. Two suggestions:

• Keep the quick controls on the ribbon and put the deeper Tracking: feature parity with GeoLibre #77 options in the pane, so the new tab doesn't end up scrolling like Style does now.
• Fold Convert into Map Labeling rather than giving it a group of its own.

The layer chooser would help on Data too. If we adopt the tab, Style's sentence drops "labelled".

[jgregoriorincon]

Thanks, @Mavrick-F. Both suggestions go the way I'm after: everything about labels well organised, easy to read, with room to breathe between so many controls, rather than packed into one strip.

• The pane holds every setting, the tab only the everyday ones, as today: on/off, class, field, size, colour, bold, halo, placement and range. The less frequent ones stay in the pane only: font, italic, line placement, SQL, and what Tracking: feature parity with GeoLibre #77 brings (offsets, priority, halo colour and width, expressions). That way the tab doesn't end up scrolling like Style does now. Step 3 of [Feature]: One place per label setting: the ribbon edits the chosen class, the Labeling pane by topic #858 splits the pane into tabs (Class, Symbol, Position, Range), so each one stays short and has room.
• Convert in Map Labeling: fine, one group fewer. Map Labeling then holds Lock, Pause, View Unplaced and Convert, and Convert's tooltip says it acts on the selected layer.

@giswqs, if this sounds right to you, I'll open an issue for the Labeling tab and send it as a small PR after the Labeling pane steps of #858.

[giswqs]

@jgregoriorincon Sounds good to me. I also agree with @Mavrick-F that we can keep the Go To XY and remove Locate. Regarding the Directions, I suggest we keep it as it is now as it kind of fits the Navigation group. The Analyze tab is currently overloaded with a long list already. We need to reorganize it first before moving Directions into it. Ideally, grouping Directions and other related functionalities as one pane.

[Mavrick-F]

@giswqs sounds good to me

[jgregoriorincon]

Thanks, @giswqs. I opened #897 for the Labeling tab. I'll do it after the Labeling pane steps of #858, so the tab follows the pane's tabs.

[deniial00]

I’ve opened #903 to put the guidelines from this discussion into the contributor docs, combining my tab-purpose proposal with @Mavrick-F’s workflow and destination-based approach.

The main points:

• Use each tab’s purpose to decide where features belong.
• Keep useful shortcuts to pane sections; merge buttons that reach the same destination.
• Keep View › Windows complete and task-specific modes beside their tools.
• Use consistent names and icons, and split buttons with a clear, fixed default.
• Check everyday workflows, clicks and tab switches—not just control counts.

This is documentation only, not a ribbon reorganisation. It gives us a shared basis for the small, tab-by-tab changes discussed here. The Labeling tab is marked as planned, and Directions stays on Home until Analyze is reorganised, following the later exchange.

Please flag anything I’ve missed or captured incorrectly, especially the tab purposes—we’ll use those to guide future feature PRs.

[deniial00]

I started implementing the changes to Home tab proposed here. This is what it looks like so far:

I didn’t really like having two columns with only two items each in Navigate, so I tried putting Go To XY and Find Place under a Locate dropdown, with “By Coordinates…” and “By Place or Address…”. That lets Planar, Identify and Locate share one column:

I prefer this version, though it does mean an extra click for coordinates or address search. What do you think?

[giswqs]

I like the second version. The empty space beneath Identify and Find Place in the first version feels odd compared to other panes.

[jgregoriorincon]

For the label side: #935 is merged. The ribbon now has a fixed Labeling tab after Style. It holds Labels, Label Class, Text Symbol, Label Placement and Label Range for the selected feature layer, then Map Labeling (Lock, Pause, View Unplaced, Convert). Style no longer has the label groups, and View no longer has the Labeling group, so whoever takes up Style or View next starts from the slimmer tabs.

[deniial00]

Thanks, @jgregoriorincon, for bringing the labeling controls together and making Style and View slimmer. I appreciate the work you’ve put into both the ribbon and the Labeling pane.

I supported trying this direction, and I think it was worth taking a look at it in practice. Having the controls grouped together gives us something concrete to discuss: not just where labeling belongs, but how much of it should be available directly on the ribbon.

Your earlier principle—every setting in the pane, only the everyday ones on the ribbon—makes sense to me. My preference is for the panes to be the main place for configuring labeling, symbology and future layer settings, with the ribbon providing a small selection of quick controls and easy access to the full pane. Some overlap is useful; I’m concerned about maintaining two extensive interfaces for the same settings as those features grow.

Which controls do you think benefit most from immediate ribbon access during map work, and which could stay in the pane? There’s also a broader question: does adding a dedicated tab for each area scale well as more layer settings and features arrive, or would we eventually run into the same crowding at the tab level?

I’m not suggesting we undo this change. I’d like to use it to discuss a consistent approach for labeling, symbology and whatever comes next. I’m looking forward to hearing your thoughts and everyone else’s views on this.

[Mavrick-F]

The guidelines from #903 already set this split: everyday controls on the ribbon, everything in the pane, and the ribbon editing the same state (#863), so it's one model rather than two. I'd use a simple test for which controls stay: on the ribbon if you adjust it while watching the map (on/off, field, size, placement, range, pause), in the pane if you set it once (fonts, expressions, priority, offsets).

On adding tabs: agreed that a tab per settings area wouldn't scale. Labeling earned one because it's done repeatedly during map work, its controls were split across two tabs, and Style overflowed. Most future layer settings won't meet that bar and belong in the pane.

[jgregoriorincon]

Thanks, @deniial00, and @Mavrick-F for the test. I'd answer both questions with it.

Which controls stay on the ribbon. The Labeling tab already passes Mavrick-F's test: everything on it is adjusted while watching the map, and it opens the pane for the rest (Labels › Properties).

• On the tab: on/off, the class and its field, size, colour, bold, halo, placement, the scale and distance range, and the map-wide Lock, Pause, View Unplaced and Convert.
• Pane only: font, italic, the SQL clause, halo colour and width, and letter spacing (feat(labels): a halo's own colour and width, and letter spacing, as QGIS's buffer and spacing #964 added the last three to the pane only).

The ribbon also edits the class chosen in the pane, so it is a second view of one model, not a second interface to keep in step (#863).

Where the pressure on this tab will come from is #995, which I opened to make the label engine sturdier: candidate positions, conflicts between labels, features as obstacles, and what to try when a label doesn't fit, as ArcGIS Pro's Standard and Maplex engines do. It brings many new settings (weights, buffers, fitting strategies), and the test sorts them: they are set once, so they go to the pane, in tabs of their own there. At most one or two might pass the test later, such as a quick choice of how hard the engine tries; if so, I'll bring it here first rather than add it in a PR.

Tabs. Agreed that a tab per area doesn't scale, and Labeling shouldn't be a precedent for one. Symbology stays in Style plus its pane, and most new layer settings will only need the pane.