Please escalate the following comparison to the product and engineering teams. Our workflow requires the visible hierarchy and precise stacking controls provided by Adobe Illustrator, together with independent layer-viewing controls for shared users who have view-only access.
The central issues are that Miro separates layer management from object arrangement, making the complete stacking order difficult to inspect and control, and restricts viewers to the shared visibility configuration established by editors.
1. Viewing layers versus viewing their contents
CURRENT MIRO:
The documented Layers panel manages whole layers. Individual objects are arranged separately through canvas commands. The documentation does not describe an expandable, ordered list of each layer’s objects.
REQUIRED:
Provide an expandable hierarchy showing layers, nested groups, and individual objects in their actual rendering order. Include object names or recognizable identifiers and selection indicators.
PRACTICAL DIFFERENCE:
Users should be able to inspect exactly what a layer contains and identify which object sits above or below another, including objects completely obscured on the canvas.
2. Changing object order versus choosing an exact position
CURRENT MIRO:
Object ordering uses Bring to Front, Send to Back, Bring Forward, and Send Backward. These commands change relative position, but the documented workflow provides no corresponding object list in which to inspect the before-and-after order.
REQUIRED:
Allow users to drag individual object entries to an exact position within a layer, as Illustrator does. Show an insertion marker before the drop and update both the list and canvas immediately.
PRACTICAL DIFFERENCE:
I should be able to place a label directly above a particular line and below a particular symbol in one operation, with its resulting position visible in the panel.
3. Whole-layer order versus order within a layer
CURRENT MIRO:
Dragging layers in the panel changes which layer’s content appears on top. Object-level arrangement commands are documented separately, without clearly explaining their scope across layers and groups.
REQUIRED:
Apply an explicit hierarchy:
- Layer position determines order between layers.
- Group and object positions determine order within their parent.
- Arrangement commands operate within that parent.
- Moving an entire layer preserves its internal object order.
- Changing layer membership requires an explicit move.
PRACTICAL DIFFERENCE:
“Bring to Front” should have a predictable meaning. Users should know whether it means the front of a group, a layer, or the board before executing it.
4. Moving content between layers
CURRENT MIRO:
The documented workflow requires selecting canvas content and using a menu command to move that selection to a destination layer.
REQUIRED:
Also support dragging object entries between layers in the panel. Distinguish placing an object inside a layer or group from placing it above or below another object. Display the resulting parent and stacking position.
PRACTICAL DIFFERENCE:
Users should be able to change membership and placement through the same visible hierarchy while preserving coordinates, dimensions, and alignment.
5. Activating a layer versus isolating its contents
CURRENT MIRO:
Selecting a layer establishes a destination for new content. Miro’s published support response states that an active layer does not restrict selection or interaction to its contents.
REQUIRED:
Provide an explicit layer-isolation mode, comparable to Illustrator’s isolation controls. While enabled, selection and editing should be restricted to that layer, with a clear indication of the active scope.
PRACTICAL DIFFERENCE:
Users working on infrastructure annotations should be able to select and edit those annotations while keeping surrounding imagery and other layers protected from accidental selection.
6. Default Layer exceptions
CURRENT MIRO:
The Default Layer cannot be hidden or locked. New content goes there when another layer is not active.
REQUIRED:
Provide consistent visibility and locking controls for ordinary content layers, including the initial working layer. Clearly display the destination for new objects and explain placement rules for pasted and duplicated content.
PRACTICAL DIFFERENCE:
Users should be able to protect or hide any working layer and identify where new content will be placed before creating it.
7. Separate layer systems and special containers
CURRENT MIRO:
Canvas layers and Diagram layers operate independently. Objects belonging to a Diagram cannot also be assigned to a canvas layer. Frames also have special ordering behavior and remain behind board objects.
REQUIRED:
Expose these container boundaries in a coherent hierarchy. Show which container owns an object, which ordering rules apply, and why a particular move is restricted.
PRACTICAL DIFFERENCE:
Users should be able to understand an object’s placement from the interface without discovering container restrictions through trial and error.
8. Transparency of the displayed order
CURRENT MIRO:
The panel shows whole-layer order, while internal object order is controlled through separate commands. This leaves the complete relationship between the displayed list and the rendered result insufficiently visible.
REQUIRED:
Make the default panel order an authoritative representation of rendering order: higher entries appear in front of lower entries within the same parent. Any alternative organizational sorting should be clearly labeled and its effect on rendering explicitly stated.
Selection, activation, locking, and visibility changes should preserve stacking order. Reordering should preserve geometry and support reliable undo/redo.
PRACTICAL DIFFERENCE:
The panel should show both the current order and the result of every ordering change clearly enough that users can predict the outcome before making it.
9. View-only users cannot independently choose which layers to view
CURRENT MIRO:
Viewers and commenters cannot access the Layers panel. When an editor hides or reveals layers, those visibility changes apply to everyone and persist after the board is reloaded.
Consequently, a view-only user receives the visibility configuration left by an editor and cannot independently switch to another layer or reveal a hidden overlay. This restriction also applies when the layers are unlocked.
Layer locking prevents content edits. Shared visibility settings and the viewer’s lack of layer controls cause the viewing limitation.
REQUIRED:
- Give view-only users access to a layer-viewing panel.
- Allow them to show, hide, or isolate layers that the board owner has made available for viewing.
- Store those choices as individual viewing preferences, separate from the board’s shared visibility settings.
- Preserve all editing restrictions and content locks.
- Keep each viewer’s choices independent of other viewers and editors.
- Provide a “Reset to default view” option.
PRACTICAL DIFFERENCE:
A shared site map should allow a view-only recipient to switch between available technical overlays without requesting an editor’s assistance or receiving permission to modify the drawing.
For example, a recipient should be able to view drainage information while another person views electrical information on the same board.
ACCEPTANCE TEST:
An editor leaves Layer A visible and Layer B hidden. Both layers are approved for viewer access. A view-only recipient can reveal Layer B locally while the editor’s view and other recipients’ views remain unchanged. The recipient retains view-only permissions throughout.
REQUESTED SUPPORT RESPONSE
Please address each comparison individually:
- Identify any existing controls that already provide the requested behavior and explain exactly how to access them.
- Confirm the scope of object arrangement commands across groups, layers, and Diagrams.
- Explain whether a supported method currently allows view-only users to switch between available layers independently, without changing other users’ views or requiring editing permissions.
- Identify the remaining items as product limitations or defects, as applicable.
- Escalate the missing functionality as a request for a unified, expandable, directly editable Layers panel and independent layer-viewing controls for read-only users.
Our acceptance criteria are straightforward:
- - Editors can inspect an object’s parent and exact stacking position, move it to a specific position, and immediately verify the result through the panel and canvas.
- View-only recipients can independently choose which permitted layers to view while retaining all restrictions against modifying board content.
WARM REGARDS,
- ALL OF YOUR USERS