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

New Status Bar behaviour (hide status bar by default) #1991

Closed
ara4n opened this issue Aug 21, 2016 · 14 comments · Fixed by matrix-org/matrix-react-sdk#615
Closed

New Status Bar behaviour (hide status bar by default) #1991

ara4n opened this issue Aug 21, 2016 · 14 comments · Fixed by matrix-org/matrix-react-sdk#615
Labels
Milestone

Comments

@ara4n
Copy link
Member

ara4n commented Aug 21, 2016

Split out from #1761:

  • Status bar is hidden by default. It appears only for:
    • Error messages (e.g. the "connectivity failure" warning)
    • "You have N unread messages" (when scrolled up the page)
    • "Matthew and 5 others are typing" (but only when scrolled up the page)
  • Typing notifications are shown like the iMessage ellipsis chat bubble, as a phantom inline message in the timeline. To stop the timeline bouncing up and down as people start and stop typing, we debounce the timeline animation - after making room for the typing notification by scrolling up, the timeline waits N seconds (if at all?) to scroll back down again.
@ara4n
Copy link
Member Author

ara4n commented Aug 21, 2016

@antikewl - this needs a design for the iMessage-style chat bubble.

@wmwragg - i think the implementation of this can be attacked independently of that design (and independently of the rest of the autocomplete stuff in #1761)

@antikewl
Copy link

antikewl commented Sep 8, 2016

@ara4n
Copy link
Member Author

ara4n commented Sep 9, 2016

with ben's typing notification design, this is done & design signed-off

@wmwragg
Copy link
Contributor

wmwragg commented Sep 16, 2016

@ara4n This appears to be two completely different tasks:

  1. Status bar is hidden by default.
  2. Typing notifications are shown like the iMessage ellipsis chat bubble, as a phantom inline message in the timeline.

Shouldn't these be two separate tickets

@ara4n
Copy link
Member Author

ara4n commented Sep 16, 2016

sorry, i conflated them together as the act of hiding the status bar means that we need somewhere else for the typing notifs to go. you can't really have one without the other. happy to split though if it helps!

@ara4n
Copy link
Member Author

ara4n commented Sep 16, 2016

I'm a bit worried that the process of showing & hiding the statusbar could be a bit of a nightmare in terms of causing the main TimelinePanel to change shape and lose offset etc. It might be worth a quick initial investigation, but if it's looking too invasive (given we're meant to be frozen) i'd deprioritise it.

@ara4n
Copy link
Member Author

ara4n commented Sep 16, 2016

see #2237 for the typing notif look & feel ticket, but that has a dependency on this one.

@wmwragg
Copy link
Contributor

wmwragg commented Sep 16, 2016

@ara4n It's proving ridiculously difficult to show/hide the mx_RoomView_statusArea in the RoomView, it's used by so many different components, some determine their own show behaviour, but expecting to always be viewable. I think I'm getting a feeling for how the spaghetti hangs together, but this is going to be a fairly long ticket. Just warning you, so if you want to deprioritise this let me know.

@lukebarnard1
Copy link
Contributor

@ara4n I've got a PR for this which is undeniably slightly awful, because the status bar uses the client peg to get it's state instead of having it passed in from RoomView. Thus it is necessary to have a couple of callbacks that tell RoomView when it's visible/hidden.

@lukebarnard1
Copy link
Contributor

Should this be closed now? Or should we close it once we've actually gone and put the typing avatars in the TimelinePanel itself and done the animation via actually scrolling the scroll panel?

@ara4n
Copy link
Member Author

ara4n commented Feb 2, 2017

We've had a week or so to play with the current implementation, and I'm a bit worried that it may not be far enough along to actually be considered an improvement.

Specifically, the intended design here is to mimic iMessage: that typing notifs are shown as if they are a new message... and critically when the user stops typing by sending their message, the typing placeholder morphs directly into the real message, rather than the statusbar hanging around later.

This means that the statusbar transparently collapses again, rather than the current situation where 10s after anyone sends a message, you get the separate & very distracting collapse animation happening. This means that the only time you see distracting and annoying collapse animations is in the unlikely scenario of someone who starts typing, and then thinks better and stops. Which we could even consider sufficiently unlikely to kill the collapse animation entirely. Meanwhile, for the full effect, we'd really need the same animation when people add messages to the room too (if we're animating the appearance of the typing notification, given that it should 'feel' like a normal message to the user).

My current feeling is that we should disable this (or make it an optional setting) until we've gone the whole hog to implement this behaviour, otherwise it keeps bouncing up & down way too much, even with the debounce logic. @superdump and @aliencq and others have already WTFed fairly loudly at us on this.

@lukebarnard1 wdyt?

@uhoreg
Copy link
Member

uhoreg commented Feb 2, 2017

This means that the only time you see distracting and annoying collapse animations is in the unlikely scenario of someone who starts typing, and then thinks better and stops. Which we could even consider sufficiently unlikely to kill the collapse animation entirely.

That scenario isn't that unlikely. I do it all the time. ;)

FTR, I also don't like how when I scroll up in the timeline and then back down the statusbar hangs open for a long time. I think the statusbar should close immediately after scrolling down to the bottom, if there are no other notifications.

IMHO, the current behaviour would be fine with the following tweaks:

  1. when a new message appears, then hide the statusbar if there are no current notifications
  2. when the user scrolls to the bottom of the timeline, hide the statusbar if there are no current notifications.

Another thing that may help is to fade out the typing notifications gradually in the case where someone starts typing and then stops, so that the statusbar isn't completely empty for so long.

@lukebarnard1
Copy link
Contributor

Forgot to respond to this before. I agree (albeit a bit late anyway) and have started implementing the Real Deal ™️ here: matrix-org/matrix-react-sdk#728

@turt2live
Copy link
Member

I think we ended up doing this... Please reopen and clarify if I'm wrong

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants