@hmhealey This is the current behavior, but agreed we should improve this experience. cc @asaadmahmood

I could take a look at this if you still think it should be improved :)

That would be awesome, thanks @michkrej! Added some high level requirements below to help. Let us know if you have any questions! cc @asaadmahmood for any additional input.

Requirements

1. Creating a new card on a board does not automatically save unless the user adds content or makes changes to the card
2. "Untitled" cards can still be created as long as something on the card was changed or added, such as a property, comment, description, or icon.
3. When creating a new card from a column on a board view, a value from the respective SELECT property is automatically added to the empty card - do not save the card unless the user makes any changes to the card.
4. Same for all other views, including Table, Calendar, and Gallery views, as well as card templates - when a card is added to any of those views, do not save the card unless content was changed.

@asaadmahmood does for example adding an empty text block count as added content or does the user need to also write something for the card to save?

@michkrej I think we should save it in your case. We're trying to minimize accidental card creations, so if a user manually makes a change to a card, including adding an empty text block, then we can assume that the card was not accidentally created. Hope that clears things up, but let us know if you have any other questions. Thanks!

@wuwinson what should happen when user clicks to create a new card, types some characters in title, then erase all of the characters and closes the card dialog?

Great question @kamre! That also brings up other use cases where a user can make a change to a property on the card, or add text to the description, then undo the changes. We need a better definition of what is considered a "change" in those cases.

Option A:

• Consider any manual keyboard input and adjusting of properties from the user as a "change" to the card and save the card even if the card does not look any different from when it was first opened.

Option B:

• Check the difference between when the card is first opened and when the user closes the card - if there is no difference, do not save the card.

Open to other ideas as well. Would like to keep this simple from a user experience and technical implementation standpoint. I think either of these options would reduce accidental card creations, but also want to make sure we don't prevent users from saving a card when they're actually trying to do so.

From the user interactions I have had at my job I definitely think that option A will cause less confusion. Option B could work if it comes with some type of warning text that the card won't be saved. What do you think @kamre

@michkrej @wuwinson I also think that option A will have less confusion, i.e. if there was any interaction then the card should be preserved.

Thanks for your input @michkrej @kamre! Let's move forward with Option A then!

Just wanted to update that I'm still working on this! University is currently kicking my ass.

Awesome, thanks for the update @michkrej!

Currently working on an approach and just wanted to check if the implementation sounds alright or if I'm heading in the wrong direction @wuwinson

1. When a card is created it is created with the property notSaved: true. I then check against this in all places where a newly added card can be modified and save the card to the database if notSaved is true. The notSaved property is not saved to the database to not take up unnecessary space.

2. Another approach could be to add a prop called modified: false when a card is created and then change it to true when something in the card is modified. Then when the user closes down the card we check if it has been modified and if that is true we save it to the DB.

Which approach would you prefer? Do you maybe have another in mind?

Thanks for reaching out @michkrej! @jespino Do you have any thoughts on the 2 proposed solutions above to prevent saving accidental card creations? Thanks! cc @sbishel

@michkrej you are talking about the database, but if you replace that concept of "database" with the "API call", that sounds sensible to me. I think it is something that can live in the client side, and that allows you to pre-create the card in the store without really sending it to the API. Then, whenever you try to save any fields, check if is already created the card, and if not, create the card first, and then, update the field. For me this is 100% frontend work.

@jespino sorry wrong choice of wording. I'm talking about API calls and I'm aware that all the work will be done in the frontend. My question really is if you think it is best to write my solution in such a way that I only do the API call (the call to save the card to the database) before closing down the issue (1) or if I can add the API-call to all places that can modify a card (2).

Option 1 means that I have to modify the state of the card in several places while Option 2 means the API call exists in a bunch of files. Guessing you would prefer option 1? I think that either of these approaches would reduce the number of calls to the backend instead of checking if the card already exists in the database each time a field needs to be updated. Or is there a reason that you would prefer me to check if the card is already created each time instead of using a temporary property?

@michkrej sorry, probably I didn't do well with the wording, with the "check if the card is already created" I meant using your extra property, not calling the API. So yes, I prefer the first option because is cleaner, any card that comes from the server doesn't have the property "notSaved" so "notSaved" is false by default.

TLDR; yes, option 1 sounds good to me, and check if doesn't exists means check if the new notSaved field is equal to true.

@jespino great, thank you! Have great weekend :)

Related to #4476. @michkrej Just checking in to see if you were able to make any progress on this. Thanks!

@wuwinson unfortunately not, I've been struggling with making focalboard run as a plugin and haven't been able to fix it. Unfortunately, I probably won't have any time to look at this going forward so I will unassign myself. Sorry for the trouble!

All good @michkrej! Thanks again for trying to help us with this enhancement!

I just created a $100 bounty on Opire, you can add more bounties and we can create a common pot to see if anyone is willing to solve the issue 🙌

I’ll take a look at this!

/try

@jav974 can I take it up?

@jav974 can I take it up?

@Lokendra-sinh what do you mean ? i submitted a PR so we'll see