Skip to content

Message editing: Ensure the timeline layout doesn't change when editing #9752

Closed
matrix-org/matrix-react-sdk
#8483

Description

@nadonomy

New design:

EditingV2

  • Edit UI shouldn't impact timeline layout, leaving a gutter on the right for read receipts
  • Z index should ensure the Edit UI is above the composer, and below the room header
  • Adding new lines should grow upwards (as now)

Activity

  1. bwindels commented on May 20, 2019

    @bwindels
    Contributor

    Edit UI shouldn't impact timeline layout, leaving a gutter on the right for read receipts

    should be addressed by matrix-org/matrix-react-sdk#2996

    Z index should ensure the Edit UI is above the composer, and below the room header

    Postponed this for now.

  2. bwindels commented on Jul 15, 2019

    @bwindels
    Contributor

    I think the plan is to have another look at the layout of the edit UI (what Matthew said AFAIR), so postponing the remaining overlay work.

  3. nadonomy commented on Jul 15, 2019

    @nadonomy
    ContributorAuthor

    EDIT: (In-line quoting my original message as it seems GitHub flavoured markdown doesn't support strikethrough anymore?)

    I remember we had some discussion about not having the bottom left of the panel occlude the timeline but arrived at a place where that direction didn't make sense as (a) it's ok to occlude the message below, as you're interacting with edits contextually (b) it would be inconsistent with the rest of the UI and (c) it robs us of a sensible place to put the formatting legend.

    @ara4n can you be more specific about what you wanted to take another look at?

    Notes from some internal discussion (starting here):

    • In general, we're happy with using the current edit UI
    • However, we're not too happy with the edit UI popping when being used on the last message in the timeline
    • There's a suggestion from @ara4n to move the buttons in the right hand gutter, however I'm extremely reluctant to want to make that change as it'll suffer from poor discoverability and eschew established UI conventions
    • @bwindels feels it would be weird to have the edit UI chrome overlay the composer, and also flagged it would involve a huge technical undertaking

    Given all of the above, I think the UI popping on the last message is the correct trade off to make, so would advocate either to maintain that, or leave this issue open for future discussion.

  4. ara4n commented on Jul 15, 2019

    @ara4n
    Member

    i'm still not entirely convinced that occluding the content below is necessary or desirable, and it certainly makes implementation harder for stuff like occluding the composer. totally agreed that this is low prioity though.

  5. nadonomy commented on Jul 15, 2019

    @nadonomy
    ContributorAuthor

    Just had a thought— the right gutter approach could work if we use icon based buttons and colour to provide more contrast for the eye (green tick button, red cancel). I'll do a comp in due course and we can see how we feel about it, perhaps with us in-lining/absolute positioning the formatting legend within the composer chrome.

  6. bwindels commented on Jul 15, 2019

    @bwindels
    Contributor

    Sgtm. Wrt to the legend, I think the idea is also to display it in the main composer in the future, so might not need to display it twice.

  7. added 3 commits that reference this issue on May 28, 2022
    b3df0a6
    359bd71
    1ad4250
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions