Wait / delay indication
Closed this issue · 7 comments
There are times (during login, room selection, sync) when the UI is very slow and need some visual feedback to the user
Perhaps a progress bar? Example while waiting for wifi connect.
checkout the chat readme
I think the UX overall should have an extra status bar devoted just to the chat function. Perhaps an extra line of text across the top that shows things like wait/delay, which Dialogue you're in, and so forth. This status bar can be used to help hint to users during the on-boarding process as well (indicating a lack of credentials or lack of connectivity to servers).
I think ... maybe just something like a "marching ants" style animation in a bar that divides the security status from the extra status could be our wait indicator. The idea is to have something that's computationally lightweight and minimizes the amount of vertical real estate that has to be redrawn (this impacts the refresh rate of the screen, due to the hardware protocol of the memory LCD).
So the animation would "march along" when something is in progress, and stop when things are done.
There's a question of how best to implement the animation start/stop.
I can think of three ways to do it. In all cases, the animator is its own thread.
- Shared Arc::Mutex::AtomicU32 that indicates if the animation should run. Everyone who could do something "substantial" gets a clone of the AtomicU32 and increments it when they are busy and decrements it when they are done.
- A server that runs which receives messages from anyone who can connect to it that starts and stops the animation.
- The animation is owned by the "main loop" and the main loop sets it to run whenever it's not idle, and stops it when it's idle.
(1) has the benefit that an AtomicU32 is lightweight and fast. It has the downside that you have to pass it around to everyone who needs it.
(2) has the benefit that you don't have to pass around a variable to every function that needs it. You can just hack in a connection to a server if you realize later on that "oh, this should probably indicate waiting". The downside is sending a message is just more thrashing when things are busy.
(3) is actually the lightest weight messaging mechanism because there isn't any shared state required, but has the downside that you'll get animations triggering when almost anything happens, from minor updates to fairly major events.
I'm going to look at the structure of the mtxchat app a bit more and try to figure out which one of these approaches make the most sense, but happy to hear other thoughts/opinions about this in the meantime.
I think a chat status bar could work pretty well - while taking care to minimise the vertical real-estate used.
I wonder if the status bar might temporarily re-use the real-estate occupied by the text entry area?
I think a marching ants animation would benefit from a simple text explanation of that we are waiting for.
I wonder if a status bar might actually be a compact form of a modal - able to show a one-line notification, a basic ok/cancel question, or a progress indicator (marching ants)? If this compact modal were displayed at the bottom - then it would be natural to use F1-F4 keys to answer simple questions.
Implementation option (3) seems the most simple alternative to me.
@nworbnhoj Making the status bar an additional window that "floats" over the chat doesn't work because in theory there should only be one active window that's responding to events at any time. Background windows are supposed to be inert, by design. I know, kind of sucky for overall UX but it was a design choice to try to minimize phishing by malicious apps that present copies of legitimate dialog boxes for nefarious purposes.
Re marching ants with text -- I was thinking about that a bit more, I think you're not wrong that's a pretty nice thing to have. However, implementing marching ants over text is a little bit tricky because you're not allowed to composite text directly at the GUI layer (otherwise you could forge a password box (only highly trusted apps are supposed to be able to render inverted text).
No worries though, I thought about it a bit and maybe what I can do is extend the TextArea object with a marching_ants feature -- if it's active, it'll render some sort of barber-pole stripe effect over a line of text (basically an XOR invert of black background over segments of the text). Probably the caller would need to provide a little bit of state -- there would be a parameter you have to increment from the application that controls how far along the ants have marched. But basically every time you go through a loop you can update that variable and you'd get a barber-pole stripe animation that appeared to go from say, left-to-right with every iteration through the main loop.
That could be just a generic primitive I can make available first, and then that'd get layered into the status bar text.
I think a marching-ants effect is more appropriate anyways for stuff like TLS negotiations and talking to the Matrix servers, because if the comms fail you'd have a retry and you can't predict in advance how many retries you'd have (I guess you could estimate a %age and knock it backwards everytime you had to retry a handshake but that's more complicated than it's worth I think -- marching ants is an easy effect that just acts as "comfort noise" to the user).
Stumbled over this while waiting for the (emulated) chat client to sync. Some thoughts:
I think the UX overall should have an extra status bar devoted just to the chat function.
Do you mean even when in other apps? I am new to precursor and xous, so sorry if that obviously doesn't make sense.
So the animation would "march along" when something is in progress, and stop when things are done.
I don't know the internals, but it sounds like there may be more than one substantial thing to wait on. In that case, it might sometimes be helpful to understand what we are waiting for. Maybe instead of add/subtract, you could set/clear a bit, and use different bits for different indicators. I guess that's not as reliable when a wait condition can be set in different places (because it's not commutative/eventually consistent), but if it is clear that a bit is only set in one place, this should work.
Making the status bar an additional window that "floats" over the chat doesn't work
Regarding "action needed" situations: if there are different indicators (regardless of how they are driven), there could be an indicator for "interaction required" and one of the F keys opens a modal that allows the user to handle that dialog. The idea here being removing as much friction as possible within the constraints of the system.
Hm, just noticed it's not just not syncing, it complains that I am not in the channel. I'll try to get that working...
@keks There is some WIP here FYI #443
The current idea is to show an extra status bar only while in the mtxchat app.
Indeed there may be more than 1 substantial thing to wait on - we are currently working with the idea of displaying both a wait-animation and a short line of text to explain the wait (checkout the WIP link above). There will certainly be network related delays, but also maybe internal delays relating to pddb access for example. Both mtxchat and the sigchat rely on a common chat-UI (see libs/chat). The idea is for the chat-UI component to manage what is actually displayed in the status bar (when there are multiple concurrent waits for example)
Yes - the current idea will allow the chat-UI to use the status bar in "action needed" situations.
I think that #443 adequately addresses this, if you agree please close the issue @nworbnhoj