I haven’t started looking for alternatives, since most of the functionality I need for our plugin is provided. But I do share your feeling of abandonment a little. There are 2-3 things I have been missing and not seen any progress on for several months.  

Though I have seen some Items move around on the Roadmap, a fairly long time ago, the lack of progress/communication in this area is a little concerning.

Hey @Geir Ølnes @aurech,

Thank you both for your valid points and feedback—It’s definitely valued by our entire Platform team at Miro. 

We definitely have some gaps that are missing from V2 compared to V1, and we know that some of the missing features are important for you and our community.

Our roadmap is still the best place to see the features we’re working on, and suggest new features for us to consider for the next iteration of our Platform.

One thing I’d like to ask, if you have any specific workflows or features in the apps you’re building that are not being met by the missing features of the V2 Platform - This will help us understand a bit more about the use-cases our community is building for, but also help me think if there are any workaround I can provide to get you unblocked. 

Let me know - 

Addison

For me the show stoppers are:

• The on attribute must be extended with equivalents of  "WIDGETS_CREATED",  "WIDGETS_DELETED",  and "WIDGETS_TRANSFORMATION_UPDATED"
• CRUD of Lines/Connectors

The high priority ones are:

• Icons (as I feel it is a shame to convert the simplisity of an icon widget to the complexity of an image widget)
• metadata at widget level 

Why it is needed:

• I need to draw and delete lines from the application because the connections between objects are context dependent
• I need to know when a card is moved to know where it belongs (as on a canban board).
• I need to know when a line is created or deleted to record or delete the connection in the right context.
• I need metadata on widgets to tell their functionality to the application.
  • I need to tag some frames to tell the application that this is a machine, not an arbitrary frame of information. Without metadata I need to parse all content of all frames to guess their functionality.
  • I need to tag shapes to tell the application that a shape contains a text to be interpreted as the max, min, or likely value for the machine (and otther attributes). Without metadata I need to parse a grid of lead texts and assume the functionality based on the shape´s coordinates within the grid. This is vulnerable to users moving texts or shapes.

Thanks for the response @Addison Schultz , that’s all good to know.

I’m working on an {issue-management-system}-Cards app, and one of the features we have on prod with v1 is visualizing dependencies between the items with lines / connectors, which adds rather valuable insight (and of course takes away that manual work.)  

I also envisioned doing this by grouping Items in frames instead (to reduce potential spaghetti on the screen), which I imagine would be covered from your side with the “Group Items” Roadmap item.

Metadata is something that seems very basic and just overall useful, specifically to save just the Items’ ID already, although I can work around that with customFields or just filtering it out of a title.

We also used the WIDGETS_CREATED event experimentally to (in our data source) create either new relations between our Items or new Items altogether.

And as you have seen in my seperate Topic, the enforced Modal padding bugs me because my in-frame modals then look ugly ;)

Hi folks,

I just wanted to chime in here to provide some reassurance. We’re definitely aware of the gaps that have been identified above, and do plan to address connectors, client side events, and widget level metadata before we sunset v1 (likely in that order).

Throughout the development of the v2.0 platform, we have been sequencing work by use case. We started with enabling integrations, and expect to remain focused in this area for a few more months, especially with the Web SDK. Diagramming will follow (already available as an experimental feature in the v2.0 API), followed by collaborative apps.

Client side events and widget level metadata are part of the collaborative apps scope. Although they were available in Platform 1.0, there were some serious limitations that we intend to address in 2.0, which will enable easy development of more powerful apps. For example, in 1.0, client side events would only fire in response to activity by the current user, and there was no reliable way to listen for changes to widget metadata.

Apologies for the lack of updates on the roadmap for the Web SDK. We will endeavour to keep that up to date and active, although there are some improvements we like to keep to ourselves until they are fully baked. ;)

Many thanks for your feedback, and your engagement with both the platform and the community. We do appreciate it!

Thor

(Head of Product, Miro Developer Platform)

Hi everyone, 

Just to make sure that I understand this correctly. (Warning, this might sound blunt but I just want to create some clarity)

• 1.0 has not yet entered the 6 months deprecation phase
• Although the mentioned issues are important, they won’t be worked on for the foreseeable future. It will take a few more months before you will start work on the initiatives that in part require these functionality. Realistically speaking we should probably not expect any changes before…? I suppose earliest start of 2023Q2?
• You are unable to communicate more to the development community because not all initiatives can be made public due to lack of internal commitment and inability to communicate reliable launch dates.

From this I deduce that anyone that wants to make progress on their Miro Plugin which needs these functionalities should not invest in migrating to 2.0. 

Things are what they are now, there isn’t a lot the community can do about it, but I do know that this uncertainty has kept me from committing work to my plugin the last 3 months in the hope that some progress would be made. None of the things I discovered during the beta program have been addressed and I only found more gaps between v1 and v2 since. At this point I'm wondering if this ecosystem is reliable enough to make significant investments in. Are there any assurances we can get in regards to future API deprecation?

I love Miro and I’m excited about the possibilities of enriching the experience with plugins. I hope we can start an ongoing conversation with this community of developers. 

Cheers, 

Marijn

Hi @Marijn Huizendveld,

First, thank you again for taking the time to share this feedback with us—we know it can be frustrating to navigate roadmaps, feature parity, and deprecations more generally. I wanted to quickly cover a few of the points in your last post.

1.0 has not yet entered the 6 months deprecation phase

You are right, we will announce the 6 months deprecation phase after addressing the gaps we have identified (more detail in Thor’s message above). 

Although the mentioned issues are important, they won’t be worked on for the foreseeable future. It will take a few more months before you will start work on the initiatives that in part require these functionality. Realistically speaking we should probably not expect any changes before…? I suppose earliest start of 2023Q2?

This is not correct. The teams have started working on some of these initiatives already. We don’t have a clear ETA yet but we expect the support of connectors on the Web SDK during Q4 2022. Client-side events and widget-level metadata should follow. We will keep the public roadmap up to date so you can track ongoing progress. 

You are unable to communicate more to the development community because not all initiatives can be made public due to lack of internal commitment and inability to communicate reliable launch dates.

Thor has shared in this thread some of the “new” features coming or at least what our priorities are. While we do our best to share pertinent details as soon as possible, there are some updates the team is working on that we can’t quite communicate yet for strategic reasons.  We strive to be as transparent as we can with the developer community by offering various communication channels in which our platform team members are answering questions developers might have and by maintaining a public roadmap to give visibility to what is in our backlog and what we are working on. Your feedback is really valuable to show us how we can improve this process. Sometimes, there are features we cannot communicate publicly until a specific moment, for business and strategic reasons. While I understand this can be frustrating, I can assure you that we are not lacking internal commitment and investment in the developer platform. I must admit though that having reliable launch dates is sometimes difficult and something we are improving one sprint after another and hopefully you will see this reflected on the public roadmap. In addition, we have started running experimental testing where we expose early features to the developer community so they can test and share feedback to make sure the features we are building meet their needs. We have been engaging with quite a few developers as well when working on new features, sharing design documents with them before we start development,  to ensure we are delivering features that meet the quality requirements. 

Regarding gaps between v1 and v2, we know it’s important to call these out, and we have documented the gaps we are aware of in our Migration guides. Please let us know if we missed anything. Our recommendation is to migrate to v2 only if you have the set of features you need to replace the functionalities you were using in v1. If not, we recommend you wait until we deliver the missing features in v2. 

Once again, thank you very much for taking the time to share this valuable feedback. We truly value your engagement with the developer platform and the community.

Best,

Anthony