Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Empty cards are created when no changes are made #4843

Open
hmhealey opened this issue Sep 8, 2022 · 21 comments
Open

Bug: Empty cards are created when no changes are made #4843

hmhealey opened this issue Sep 8, 2022 · 21 comments
Labels
Enhancement New feature or request Hacktoberfest Help Wanted Extra attention is needed Up for grabs Looking for a contributor to fix it

Comments

@hmhealey
Copy link
Member

hmhealey commented Sep 8, 2022

Steps to reproduce the behavior

  1. Click on the "+ New" button to make a new card
  2. Immediately close the modal without making any changes

Expected behavior

A card isn't created automatically unless the user enters some text or makes some changes. It feels too easy to accidentally create cards that you didn't mean to.

Screenshots (optional)

Screen Shot 2022-09-08 at 11 32 24 AM

Edition and Platform

  • Edition: Mattermost Boards on community.mattermost.com
  • Version: v7.2.1
@wuwinson wuwinson added the Enhancement New feature or request label Sep 8, 2022
@wuwinson
Copy link
Contributor

wuwinson commented Sep 8, 2022

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

@wuwinson wuwinson added Hacktoberfest Help Wanted Extra attention is needed Up for grabs Looking for a contributor to fix it labels Oct 7, 2022
@michkrej
Copy link
Contributor

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

@wuwinson
Copy link
Contributor

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.

@michkrej
Copy link
Contributor

michkrej commented Nov 3, 2022

@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?

@wuwinson
Copy link
Contributor

wuwinson commented Nov 3, 2022

@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!

@kamre
Copy link
Contributor

kamre commented Nov 3, 2022

@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?

@wuwinson
Copy link
Contributor

wuwinson commented Nov 3, 2022

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.

@michkrej
Copy link
Contributor

michkrej commented Nov 3, 2022

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

@kamre
Copy link
Contributor

kamre commented Nov 4, 2022

@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.

@wuwinson
Copy link
Contributor

wuwinson commented Nov 4, 2022

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

@michkrej
Copy link
Contributor

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

@wuwinson
Copy link
Contributor

Awesome, thanks for the update @michkrej!

@hmhealey hmhealey removed the Up for grabs Looking for a contributor to fix it label Nov 21, 2022
@michkrej
Copy link
Contributor

michkrej commented Nov 29, 2022

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?

@wuwinson
Copy link
Contributor

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

@jespino
Copy link
Member

jespino commented Dec 2, 2022

@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.

@michkrej
Copy link
Contributor

michkrej commented Dec 2, 2022

@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?

@jespino
Copy link
Member

jespino commented Dec 2, 2022

@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.

@michkrej
Copy link
Contributor

michkrej commented Dec 2, 2022

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

@wuwinson
Copy link
Contributor

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

@michkrej
Copy link
Contributor

michkrej commented Jan 17, 2023

@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!

@michkrej michkrej removed their assignment Jan 17, 2023
@wuwinson
Copy link
Contributor

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

@wuwinson wuwinson transferred this issue from mattermost/focalboard Apr 20, 2023
@wuwinson wuwinson added the Up for grabs Looking for a contributor to fix it label Apr 20, 2023
@sbishel sbishel transferred this issue from mattermost/mattermost Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request Hacktoberfest Help Wanted Extra attention is needed Up for grabs Looking for a contributor to fix it
Projects
None yet
Development

No branches or pull requests

5 participants