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.

Sign up for GitHub

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

Jump to bottom

Confusing UI wording when editing scheduled post #2704

Closed
mcclure opened this issue Sep 21, 2022 · 2 comments · Fixed by #3103
Closed

Confusing UI wording when editing scheduled post #2704

mcclure opened this issue Sep 21, 2022 · 2 comments · Fixed by #3103

Comments

@mcclure
Copy link
Collaborator

mcclure commented Sep 21, 2022 •
edited

Tried editing a scheduled post and the language confused me.

Observed behavior:

Wrote a post. Tapped "schedule". Scheduled for 1 week. Went into left side bar, scheduled posts, clicked the pencil. Changed the text. Backed out.

The post button read "toot". The back out dialog asked if I wanted to "Save a draft" and said "Delete" and "Save".

Problems:

Minor: Button saying "Toot" would be more accurate saying "Update" or "Save"

Major: Back out dialog is inaccurate. It's really asking if you want to save your changes to the scheduled tweet. Moreover, neither button does as it says. "Delete" does not delete and "Save" does not save. In either case you return to the scheduled posts listing with your changes discarded.

Expected behavior: In addition to maybe altering the "Toot" button, the dialog should reference a scheduled post rather than a draft. The buttons should be changed in any of the following ways:

  1. Text should ask if you want to save changes to scheduled post. Buttons should say "Discard" and "Save"; clicking one should discard changes and the other should save them.

  2. Text should ask if you want to save changes to your scheduled post. Buttons should allow continuing to edit the post and discarding changes.

  3. Buttons can stay the same but the functionality really should either delete or save the post. (This is my least preferred option personally but it would match the behavior with drafts.)

  • Tusky Version: Self built develop branch 7684f06
  • Android Version: 12
  • Android Device: Sony Xperia 5 III USA
  • Mastodon instance (if applicable): Mastodon dot social
@mcclure
Copy link
Collaborator Author

mcclure commented Sep 21, 2022

More small thoughts:

  • The "TOOT!" button is maybe correct because if you remove the schedule from the scheduled tweet it does just become a normal toot that you are tooting. But it still confused me a little.
  • I say above if you click "Save" on the scheduled tweet nothing happens. This is wrong, it actually does save it as a draft. But that is not desirable either because now you have two copies of the post, one in scheduled posts and one in drafts.

@nikclayton
Copy link
Contributor

I'm working on this -- there are similar problems with how discarding edits to drafts are handled. PR to come...

connyduck pushed a commit that referenced this issue Dec 31, 2022
Fix saving changes to statuses when editing (#3103)
a5f479d 
* Fix saving changes to statuses when editing

With the previous code backing out of a status editing operation where changes
had been made  (whether it was editing an existing status, a scheduled status,
or a draft) would prompt the user to save the changes as a new draft.

See #2704 and
#2705 for more detail.

The fix:

- Create an enum to represent the four different kinds of edits that can
  happen
  - Editing a new status (i.e., composing it for the first time)
  - Editing a posted status
  - Editing a draft
  - Editing a scheduled status

- Store this in ComposeOptions, and set it appropriately everywhere
  ComposeOptions is created.

- Check the edit kind when backing out of ComposeActivity, and use this to
  show one of three different dialogs as appropriate so the user can:
  - Save as new draft or discard changes
  - Continue editing or discard changes
  - Update existing draft or discard changes

Also fix ComposeViewModel.didChange(), which erroneously reported false if the
old text started with the new text (e.g., if the old text was "hello, world"
and it was edited to "hello", didChange() would not consider that to be a
change).

Fixes #2704,
#2705

* Use orEmpty extension function
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix saving changes to statuses when editing
2 participants
@mcclure @nikclayton