In our organization, we have multiple Obeya’s, each on a Miro board. Some information is useful to show on multiple Obeya boards, but we want to have one single source of that information.
So our wish is to be able to have a regular frame that contains the source information and place a read-only view of that frame on multiple other boards. If something is changed in the original frame, the changes are reflected on the other boards when they are opened again.
Yes, that would be a great addition to prevent duplications etc.
single source of truth :)
its So simple . why is this not possible ?
It would offer a non destructive way to elaborate an idea .
and carry this theme, core values and direction . across the multiple boards
would not have to be updated. in real time
maybe the Workaround is a screen shot . so that if you update the source,
would the instances of this photo update across boards ?
I support this.
The current embedding workflow is clunky. My use-case is that I am an instructor. I want to create course content in a master board and have it propagated to student boards, to be updated automatically. And to allow them to layer on notes or other objects as necessary (without actually editing the source board, or adding things that would be visible to other students.
Here’s somewhat of a business case: feature enables the creation and seamless interlinkage of content for educational institutions and corporate customers, establishing a foothold in the “collaborative visual wiki” for employee manuals, project documentation, and educational material.
its So simple . why is this not possible ?
It’s certainly possible. Whether it is simple or not depends on Miro’s architecture under the hood. Something that seems simple from the user perspective may actually be a huge effort to achieve technically.
Consider that every object, every frame, every board, is bound within some other container: a sticky within a frame, a frame within a board, a board within a user account. Each of those containers has its own set of capabilities and restrictions.
If a frame were to appear elsewhere in another context (e.g. a board, an account) and to behave as a native object would in its original location, it may need to have attributes internally that indicate or advertise whether that visibility permitted. So visibility is an attribute or set of attributes (e.g. is public for all, is visible on a specific board, or for one or many users). Whether it can be edited, a la ”Read Only,” is another.
The complexity doesn’t end there. The “host board” would need to have some knowledge of it also. It then effectively becomes an object on that board also. But it behaves differently than a “local” frame, and so the “host board” has to respect that behavior.
And the complexity probably doesn’t end there. These are just the constraints I can imagine from a surface perspective. The UX team has to think through all of those things so that the behavior I described is intuitive. The engineering team probably has all kinds of its own constraints that don’t impact the user.
And that’s all just accounting for the condition of everything already being in place. It doesn’t account for the interfaces and workflow necessary to prompt the user for managing those attributes (e.g. “Would you like to make the frame you’re copying and pasting read-only?”, “Should we allow users of this board to copy and paste it elsewhere?”, etc).
Just depends on the architecture.
maybe the Workaround is a screen shot . so that if you update the source,
would the instances of this photo update across boards ?
This approach could be a great MVP, aka first iteration. I like it. In addition to “Copy as Image,” which currently exists as a context-menu function of frames, it’s “Publish as Remote-hosted Image.” When a user does this, Miro exports an image of the frame to a CDN, and the user gets a specially-formed URL that they can direct-link in another location. Miro then periodically updates the hosted image whenever the source frame is edited.
Still not trivial, but a relatively easier way to implement the feature with the potential to require far less architectural changes.
Simple or not . seems rather irrelevant :)
Perhaps I had read that this is possible in other platforms ,
In a ACAD and final cut . you can have . clusters of information ( “blocks” ) that once changed, will auto update across the platform .
Does anyone know if its possible to link an image from google drive ?
and would this image be auto updated ?
thanks
This would be great to use today, please implement.
Miro has a tendency to create documentation sprawl, and this would greatly help curtain that.