Set properties by container.

Related products: Cards

Original in French below because it is my mother language but I will add an English translation above.
I’ve already submit this idea to miro (request 167806 ), but I post it here  to challenge them.

The basic idea is that one shape can influence the properties of another when superimposed on it.

Concrete cases:

I have a grid representing a 5 sprint plan
When I drop a JIRA card a grid case, the card updates, and it changes sprints value of the card.

I have a series of rectangles, one for each user.
When I drop a note in a rectangle, the note is assigned to this user

I have a series of rectangles for various themes

When I drop a note in a rectangle, a label is added to it representing the theme.

Generic principle


To see it in a very generic way. (I think super large, after maybe a very small part has to be done in MVP)

 

Considering

  • C a "container" zone that we will configure
  • M a "mobile" element which will undergo an automatic change
  • P a property of M
  • V a valid value for the property P


We configure C so that according to the type (note, text, shape, cards, ..) of M.

If M enters or exits completely from C, the property P of M will be updated to the value V

We can add several rules for C

We can cumulate 3 types of update

  • empty property P
  • add a V value
  • remove a V value

I believe my idea is very powerful but maybe advanced for the target audience of miro.

---- 
J’écris en français parce que c’est ma langue maternelle mais j’ajouterai un une traduction en anglais.

L’idée de base c’est qu’une forme  puisse influencer les propriétés d’une autre quand elle y est superposée.

Cas  concrets :

J’ai une grille représentant un plan de 5 sprints
Quand je dépose une carte JIRA une case de la grille, la carte est mise à jour, et elle change de sprint.

J’ai une série de rectangles, un par utilisateurs.
Quand je dépose une note dans un rectangle, elle est assignée à cet utilisateur

 

J’ai une série de rectangles pour diverses thématiques

Quand je dépose une note dans un rectangle, un label y est ajouté représentant la thématique.

Principe générique
Pour voir cela de manière très générique. (je pense super large, après peut-être qu’une toute petite partie doit être réalisée en MVP)

Considérant

  • C une zone “conteneur” que l’on va configurer
  • M un élément “mobile”  qui subira un changement automatique
  • P une propriété de M
  • V une valeur valide pour la propriété P

 

On configure C pour que selon le type (note, text, shape, cards, ..) de M.

Si M entre ou sort complètement de C, la propriété P de M sera mise à jour à la valeur V

On peut ajouter plusieurs règles pour C

On peut cumuler 3 type  de mise à jour 

  • vider la propriété P
  • ajouter une valeur V
  • retirer une valeur V

Je crois que mon idée est très puissante mais peut-être avancée pour le public cible de miro.

@Adrien Painturier penses-tu que tu pourrais donner un coup de main ou d’orientation à @Christophe GESCHÉ  ?


@Christophe GESCHÉ That's a really interesting idea! Maybe it could be done as a plugin somehow. What do you think, @Max Harper?


It's already about jira plugin integration 


@Christophe GESCHÉ You misunderstand. By plugin, we typically mean community-made plugins. The Jira integration in Miro is an official integration made by Miro. Also, I don’t think the idea itself is only applicable with Jira, it could (and should) be applied to cards in general.


This is what I’m referring to:

https://miro.com/api/


Let  try  to explain what I understand.

Write a “community-made-plugin” which “listen” with an api event when an object is dragged on another. 
And let configure this “another” object to set a property in dragged object  ?

 


let try  ==> Let me try  


 


@Christophe GESCHÉ Yes exactly!


@Christophe GESCHÉ 

This make sense. 

What would you have happen in the case of removing an item from a container? Does it keep its value on the property associated with the container it just left? Or does that value go to null? I can see value in both cases. Perhaps this is something configured container by container? 


My first idea was “If M enters or exits completely from C, the property P of M will be updated to the value V”
 

But  I’ve no more challenged them :)

 Perhaps we can imagine “only set on enter”. And    considers the full board as a container, and use set  container layer  to determine  wich value would be set.

 
I explain

“If M enters completely into C, the property P of M will be updated to the value V”

Ok  If we have  C1, C2, C3  where  

  • C1 => P1 = V1, P2 = V4
  • C2 => P1 = V2, P3 = V5
  • C3 => P1 = V3, P4 =  V6


If C1 is front of C2 and C3 back to C2
and C1 in C2 in C3


“If M enters completely into C2, ...”

M => P1 = V1, P3 = V5 and P4 = V6.

 



More powerfull,… more complex


Ok  I just see my sentence was wrong

“If M enters or exits completely from C, the property P of M will be updated to the value V”
 
==>
“If M enters completely into C, the property P of M will be updated to the value V”
 If M exits completely from C, the property P of M will be updated to the value null before to check where M is drag”
 


Maybe this could be implemented in more generic and powerful fashion - any element (or a specific element type for starters) could support “rules”:

  • trigger
    • target element type (shape|card|...)
    • action - (moved into|moved from|linked to|unlinked|...)
    • possibly even external actions (API, webhook)
  • reaction (create|update|delete|duplicate shape, shape properties, ...)

With this, i can imagine e.g. creating my own board that would reflect the actual board in jira and automate a lot of stuff.

 

It could also make life of developers a hell while trying to QA this feature ;)


@Roman Plevka  

I'm sorry, I can't see the difference with my initial proposal.

I note the addition of the event, link to / unlinked. It can be interesting

On the other hand, I have trouble imagining the "add/create shape" reaction.

A reaction on the properties of the element, ok.
But "creating an element" because we are moving another is less clear.

 


@Roman Plevka  

I'm sorry, I can't see the difference with my initial proposal.

I note the addition of the event, link to / unlinked. It can be interesting

On the other hand, I have trouble imagining the "add/create shape" reaction.

A reaction on the properties of the element, ok.
But "creating an element" because we are moving another is less clear.

 

hey. sorry if this did not bring any new idea, i might have understood the original proposal wrong.

the creation of the item example:

Jira kanban -

you have a rectangle shape created and you want it to represent a specific swimlane in your jira project/board.

so you specify an API/webhook trigger to it ..and if there is a new jira card created in the target swimlane (in jira server), and its representation does not exist yet, it will be created.

Stuff like this