Cleaning up the dashboard cruft + addressing the current issues with the dashboard

[koonpeng]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

Throughout the last few months, there have been many changes made to the dashboard specifically catered certain scenarios (e.g. There are many hacks put in so that things render properly on very specific devices). There are also many areas of the dashboard that is lacking and can be improved.

• Remove special behavior based on screen size
• Bring back dark mode. Or rather, there needs to be a way to easily customize the theme.
• Improve performance of the map
• Implement trajectory on the map
• Remove negotiation manager
  - [ ] Remove reliance on hard coded task forms. Current plan is to introduce something on top of a task, called a "mission". A mission definition will include the inputs, a ui schema and a json document with json reference that defines how to convert the inputs into a RMF task. This conversion will be done by the api-server and the frontend will only work with missions.
• Add dispensers, ingestors and workcells on the map (requires RMF to report their locations)
• (low-priority) Show the predicted length of a scheduled task on the calendar
• Have a way to customize the dashboard without needing to change existing code, this is the original goal of react-components but obviously it has failed. The new approach is to combine rmf-auth, react-components and dashboard into the one package. Instead of focusing on flexible, unopinionated components, it will focus on simple and opinionated components. Meaning that instead of having components that takes data and callbacks from props, they will manage their own data and actions.

[aaronchongth]

Updated original post, shifting json form migration to #997 instead

[aaronchongth]

Updated original post, assigning lower priority to showing predicted length of scheduled task, as it can vary wildly depending on which robot gets assigned the task, and there would be follow-up difficulties of

• what happens if the nav graph changes and a task can be executed much faster than before, should the schedules already in the DB be updated to reflect the new length of execution?
• length of execution will be entirely dependent on the user's setup of RMF

I would actually suggest that we make the length of execution a part of the schedule form, with a default value of the current 45 minutes, and let the users assign more appropriate values themselves. This will also help resolve the UX issue of shorter schedules (e.g. 5 minutes), where nothing can be read from the schedule event as the event box is too small, which gets increasingly bad if users clutter a lot of short scheduled tasks together.

[koonpeng]

Updated original post, assigning lower priority to showing predicted length of scheduled task, as it can vary wildly depending on which robot gets assigned the task, and there would be follow-up difficulties of

• what happens if the nav graph changes and a task can be executed much faster than before, should the schedules already in the DB be updated to reflect the new length of execution?
• length of execution will be entirely dependent on the user's setup of RMF

I would actually suggest that we make the length of execution a part of the schedule form, with a default value of the current 45 minutes, and let the users assign more appropriate values themselves. This will also help resolve the UX issue of shorter schedules (e.g. 5 minutes), where nothing can be read from the schedule event as the event box is too small, which gets increasingly bad if users clutter a lot of short scheduled tasks together.

The length of a scheduled task is just the estimated length, it doesn't have to be very accurate. Making the user set an expected length is a possible solution. As for the user setting very short 5min schedules, if the calendar library doesn't handle that, then I guess we can consider making a PR to improve it. Google calendar for example has a minimal size.

[aaronchongth]

The library handles it properly without issue, my concern is that of readability at first glance of the schedule calendar where it is just littered with little blocks with no texts (same as google calendar if we cramp a lot of small events), I believe we should just let users configure the length, since if there is a UX issue, they can set a longer time for readability on their own