Improvements to chat UI

[joshuaauerbachwatson]

I've discovered https://github.com/exyte/Chat which is a better looking chat view (and more functional) than anything I could come up with. So, I think I will try using it as the full-panel chat view and do something even more expedient with the abbreviated chat that is part of every view. For that, I may just have the chat button and handle incoming chats with a popup.

The popup could show the incoming message with buttons Reply, Ignore, Show in Chat.

To make the popup work better I might consider https://github.com/exyte/PopupView. If I adopt that, I can also use it for error popups.

[joshuaauerbachwatson]

Maybe the right order for working on this is

• Stabilize the Chat view so it works as a full page but don't worry about shrinking it into other views
• Change the content view so it doesn't have an inline chat view and works as outlined here
• See what happens when we replace the Chat view with one derived from exyte/Chat.
• Orthogonally see if we can get serious improvements by using exyte/PopupView. Might or might not be.a win.

[joshuaauerbachwatson]

I've cleaned up the chat view and stopped showing a shrunken form of it as part of the content view. However, I have not worked on a chat popup for incoming chat messages and I just noticed that the error alert popup does not actually show the error message. So will work on the popup logic next.

[joshuaauerbachwatson]

The first two steps are done, so we could rest this issue for a while before evaluating and possibly adopting the exyte ct alternatives.

There is a possible weakness if multiple chat messages arrive when the chat view is not showing. The first will fire the alert and show up in the alert. The second and subsequent ones might be mishandled unless the user chooses to switch to the chat view and does so promptly.

I should probably take a shot at addressing the weakness before resting the issue.

[joshuaauerbachwatson]

I should probably take a shot at addressing the weakness before resting the issue.

It is trivial to add logic to only fire the alert when the alert isn't showing. This would get rid of some of the worst pathologies.

But, not firing the alert means that the message goes into the transcript without causing any alert. So, if the user doesn't choose to switch to the chat view would entirely miss the fact that more messages arrived while he was reading the first one.

Another design is to drop the chat alert in favor of a one-line subview that always contains the last message of the transcript. This would update in place without the user doing anything. So, if the user is watching he will see the messages scroll by (maybe too fast to read). If he is not watching he will eventually see the latest message (only; but probably this is more useful than only seeing the first message). He can always switch to the chat view and see a substantial tail of the transcript. He would need to do that switch in order to reply. This could generalize to an N-line suffix of the chat (where N is pretty small, else we are right back where we started).