Skip to main content

    Filter by idea status

    Filter by product

    207 Ideas

    Steve KoppelmanContributor

    Confluence embeds pinned to a specific frameDelivered

    As reviewers have noted on the Atlassian Marketplace page for the Miro Confluence integration, the integration still only embeds the entire board in a fixed-size component. This is useless for anyone using  the canvas to hold multiple diagrams..which is the whole point of Miro. As a result, I’ve got no choice but to export a static  image of the frame I want, and paste that into the page. If the diagram gets updated, my Confluence page obviously does not. And if I want to link to the Miro board, I’m best off bypassing the integration entirely and simply pasting a URL because, again, there is little or no conceivable use for embedding the entire Miro app, UI and all, not focused on the specific content I’m trying to share, into a fixed-size small frame on the wiki page. This can and should be split into multiple stories, e.g.: As a user, I should be able to embed a single live frame into a Confluence page I should be able to control the size and perhaps aspect ratio of the embedded frame, e.g. to match the content, as its dimensions are knowable. I should be able to toggle whether the full Miro app UI should be turned on in the embed by default. Just because a user *can* edit the board that doesn’t mean embeds should be covered in toolbars and minimaps. For pages that can and will be shared with viewers not authenticated into Miro, or lacking access to the specific board, there should be a toggle for an optional fallback behavior that renders a static image of the frame embedded at the time of embed creation or modification. Since your Confluence integrations go back four years, and your Confluence Cloud integration goes back at least one year, should we expect these sorts of obvious functionality will ever be taken up?

    Create / add the role of a facilitator (rights between owner and editor)Delivered

    A “facilitator” role is an essential feature for every setup where the owner of a board is not also the facilitator of a workshop where a board is being used more than one person is (co-)facilitating a workshop that uses a board more than one designer is involved in creating / preparing a board for a workshopEspecially the “hide/unhide” frame option - if used - currently prevents any board from being used by anyone else than the owner.  As long as there can be only one “owner” with the editing rights associated to this role, every setup that includes “team work” or “division of labor” on the creator side of a board would need this additional role of a “facilitator”, mainly toallow facilitators to unhide frames the creator (owner) of the board did hide allow facilitators to unlock objects that cannot be (accidentally) unlocked by (guest) editorThere are many additional rights a facilitator might enjoy over (guest) editors, including access to certain objects like frames, to prevent newbie-users to mess up a board by accidentally adding content to the board that they should not / did not intend to add. For some ideas on this, please look https://community.miro.com/wish-list-32/usage-rights-for-facilitators-vs-participants-440I understand that changing the roles might be a major intervention. But as more and more people (and teams) use Miro, this extension to the rights management would remove some painful restrictions to internal workflows of any team (not single users) that works with Miro boards on their client’s projects.