Revisit UX (might include React18)

[phraenquex]

Will update title once Boris briefs us on specific possibilities. E.g.

• loading-status of components (using suspends).
• allows upgrading json forms library (no UX impact?)
• (stack/system status. - this should be done under #1035 )

[boriskovar-m2ms]

@matej-vavrek please look into what it takes to upgrade from React 16 (quite ancient version in the fast moving front end world) to React 18.2.0 (if there is new stable version please use that one). You can also try the conversion to see what (if anything) breaks.

[phraenquex]

@matteoferla asks for job/loading status bars.

[matteoferla]

Yes, keeping uninformed users out of the dark is my worry. So a system of having a non-intrusive CSS-based pop-up-like thing (called a "toast" or "candy bar") to keep the user up to date on job progress, but also errors, whether a slow JS task is ongoing (like the Fragment vectors loading) or adding a update message (say "Server shutdown on Monday"). I implemented it in Michelanglo and I kept finding new uses and the number of "there's a bug" emails dropped because the users were not in the dark. Hence my keenness for them.

[phraenquex]

We now need scoping out how much work it would take to actually do the UX things.

[boriskovar-m2ms]

@matej-vavrek - please estimate following items - all with be implemented in the react18 branch

1. Using Suspense handle loading of tags, left hand side (this is problematic especially when using Mpro target) and right hand side
2. After pressing one of the button for hits (LHS) or compounds (RHS) using Suspense animate given button so it is clear that data are loading and also reenable progress bar in the header of the page (source is in the components/header/index,js - this progress bar to be used also for point 1)
3. Currently user has to press refresh in the project history pane to get update on the status of the job. Now we need to actively poll (@alanbchristie possibility to use something like SignalR used in C# world which enables frontend to be notified from the backend) on the status of my running jobs. It's needed to change the status in the project history, in the project table and inform user about the change using toasts (coloring analogous to colors used to indicate status of the jobs in the project history tree). @phraenquex I propose to display those toasts at the top right in the middle because if we display them at the usual position (i.e. to right coroner) they might and will in the way when user is using RHS and it can get super annoying really quickly. If we choose to use active polling strategy then we should fire up timer only when there is a reasonable expectation to receive any updates (e.g. there is at least one job running e.g. it's status is not Success, Failure or Lost - also check the code for other possible states)
4. @alanbchristie we need also backend support for messages from the server e.g. 'Planned maintenance on 24.11.2023 from 11:00 AM to 2:00 PM' or 'There is a known issue with this and this and we are working on it'. Than question is are we going to get them only when user first gets on the landing page and preview page, are we going to actively poll or are we going to use something like equivalent to aforementioned SignalR? This kind of toast should be visible until user manually closes it.

@phraenquex There was a separate ticket (or at least that's how I remember it) which I can't find for error capture and presentation to the user. We are lacking in both areas but we need to significantly improve error capture (because currently every exception ends up as a 'Cross origin error'), before we can improve error presentations. This needs to be a separate ticket.

[phraenquex]

@boriskovar-m2ms here are the ones you might be thinking of:

• 1035 (Status lights for services (ISpyB, Squonk, cluster)

• 945 ([Layout] Unlock layout causes unexpected error

I can't see others - so create the ticket if you need it (and I agree you do).

Other tickets that might now be in scope:

• (#1010 (Show save dialog on hover).

If this ticket becomes too big, we need to convert it to epic, AND review its timing.

[alanbchristie]

With regard to 4

These "management" messages open a whole new "Pandora's box". We'll need an API to create the "event" and understand "start"/"stop" times and, yes - who get's them. Is this an "event" dialogue you can open up in the f/e? And Does the f/e also offer management of the events (I suspect yes) based on a user's role? That's another issue - we have no concept of "roles" - so who can create the events, edit them and remove them. And do events have an "audience" - i.e. do they belong to a select group of people (based on Visit/Session) or are they global, or do they belong to specific "Targets" or are they attached to "issue numbers" that a user can browse? This (imo) is a whole "epic" in its own (really).

[alanbchristie]

With regard to 3

We are currently experimenting with Server Sent Events (SSE) in Squonk, and that's a complex enough feature. This will probably require the f/e (user) to "open" a "stream" and then the user will probably want to "filter" events. User's won't want (and should not) get events that they are a) not interested in or b) not entitled to see. It does open up security issues and persistence - who closes the stream etc. As with point 4 above I think this is an epic, not something that can be captured in an issue - it's another "Pandora's box" of possibilities, and "gotchas". Happy to do this but it will needs significant design.

[phraenquex]

If I understand @alanbchristie's thoughts correctly, then implementing a BEpush-FElisten pattern is A Lot Of Work.

I was assuming it'd be enough for the other way round: FE polls BE for things it knows it needs to pay attention to. Then the whole roles thing goes away. (I think?)

I suggest you discuss between you (set up separate meeting?) and then report back.

[boriskovar-m2ms]

With regard to 3

We are currently experimenting with Server Sent Events (SSE) in Squonk, and that's a complex enough feature. This will probably require the f/e (user) to "open" a "stream" and then the user will probably want to "filter" events. User's won't want (and should not) get events that they are a) not interested in or b) not entitled to see. It does open up security issues and persistence - who closes the stream etc. As with point 4 above I think this is an epic, not something that can be captured in an issue - it's another "Pandora's box" of possibilities, and "gotchas". Happy to do this but it will needs significant design.

Yes I agree that for now active polling will be waaaay easier and I think it will work well for time being.

[boriskovar-m2ms]

With regard to 4

These "management" messages open a whole new "Pandora's box". We'll need an API to create the "event" and understand "start"/"stop" times and, yes - who get's them. Is this an "event" dialogue you can open up in the f/e? And Does the f/e also offer management of the events (I suspect yes) based on a user's role? That's another issue - we have no concept of "roles" - so who can create the events, edit them and remove them. And do events have an "audience" - i.e. do they belong to a select group of people (based on Visit/Session) or are they global, or do they belong to specific "Targets" or are they attached to "issue numbers" that a user can browse? This (imo) is a whole "epic" in its own (really).

I was thinking about MVP for this feature:

1. we an endpoint to create a new message with duration since (optional) to (optional)
2. can use same endpoint to also delete given active message - either prematurely or the ones with to set to null
3. recipient is everyone
4. we need to give user an additional attribute (before we create user roles and permissions and other stuff which is epic in its own) which would mean that they can create/delete messages - I think being logged in is not enough
5. API endpoint to get all active messages

just storing my thoughts here so I won't forget

[phraenquex]

Focus of this ticket: a toast (infrastructure) top-middle that we can later populate with system messages (#1035).

[matej-vavrek]

1. Using Suspense handle loading of tags, left hand side (this is problematic especially when using Mpro target) and right hand side

2. After pressing one of the button for hits (LHS) or compounds (RHS) using Suspense animate given button so it is clear that data are loading and also reenable progress bar in the header of the page (source is in the components/header/index,js - this progress bar to be used also for point 1)

3. Currently user has to press refresh in the project history pane to get update on the status of the job. Now we need to actively poll (@alanbchristie possibility to use something like SignalR used in C# world which enables frontend to be notified from the backend) on the status of my running jobs. It's needed to change the status in the project history, in the project table and inform user about the change using toasts (coloring analogous to colors used to indicate status of the jobs in the project history tree). @phraenquex I propose to display those toasts at the top right in the middle because if we display them at the usual position (i.e. to right coroner) they might and will in the way when user is using RHS and it can get super annoying really quickly. If we choose to use active polling strategy then we should fire up timer only when there is a reasonable expectation to receive any updates (e.g. there is at least one job running e.g. it's status is not Success, Failure or Lost - also check the code for other possible states)

4. @alanbchristie we need also backend support for messages from the server e.g. 'Planned maintenance on 24.11.2023 from 11:00 AM to 2:00 PM' or 'There is a known issue with this and this and we are working on it'. Than question is are we going to get them only when user first gets on the landing page and preview page, are we going to actively poll or are we going to use something like equivalent to aforementioned SignalR? This kind of toast should be visible until user manually closes it.

1. and 2. and toast functionality were implemented in react18 branch

(we do not use Suspense for this yet, just loading indicators)

[phraenquex]

@matej-vavrek please confirm that this belongs into the "push to production" swimlane - if not, move it back.

[matej-vavrek]

@phraenquex if my previous comment here is an appropriate final state of this task, then it is alright in the "push to production" swimlane.

[phraenquex]

Thanks @matej-vavrek - let's leave it here.

Can you please create a ticket (under FragTech) with a list of things you might still need or want to do; and things hat now become possible. (@mwinokan to complement as required.)

The we can discuss it after the V2 release.

[matej-vavrek]

@phraenquex, hmm, I would say that I did everything from my part. However, there is a lot of discussion and honestly, I am not really sure what points are relevant to do or not.