Redesign of data model

[zettseb]

Problem Setting

The existing data structure of Virtual Office has grown since its initial deployment due to the incorporation of more and more additional features. This led to a comparably ill-designed data (and hence UI component) model revealing redundancies, unclear separation of concerns, and unstructured dependencies. Furthermore, two separate data concepts (the original simple RoomGrid and the newer, time-based ScheduleGrid live next to each other, i.e. the concrete implementation of Virtual Office depends completely on the type of data structure supplied. A combination of both concepts is not possible today without hard-coding the input data of the former into the latter.

The (relevant structural elements) of the current data concept (referred to as OfficeLegacy) are depicted below:

An analysis of the data model reveals several issues (not exhaustive):

• Groups must be provided (at least as empty array), even if not used.
• A Schedule, if supplied, is used (and other data not fitting into this scheme discarded), otherwise the original simple RoomGrid is rendered. In case of a Schedule, the Rooms are (hopefully) rendered in the Sessions, otherwise via Groups.
• If a Schedule is rendered, everything inside it must have start and end times.
• Sessions are used to position either of Rooms or Groups along a temporal axis, but in theory several or none of these could be assigned. A track attribute may or may not be given.
• Relation between these elements is only given by string identifiers, not composition, increasing the likelihood of broken dependencies.
• Properties active, joinable and similar are defined by time attributes from both Group and Session (redundancy and unclear separation). The two concepts don't allow the absolute same properties however. (A Session e.g. cannot be active from its start until forever. At the same time, a flexible offset before the session starts can be defined in the user config. In RoomGrids, a room might be disabled but nevertheless joinable. Lastly, the properties are defined at different levels of the component tree, see Appendix.)

In summary, while the existing data model is capable of covering all desired use cases, it is by far not logically structured, and relies heavily on the integrity of the provided data.

Solution Proposal

To a) streamline the current code basis, and b) thereby make the Virtual Office project more flexible with regards to future maintenance and advancement (incl. the development of a Virtual Office configuration UI), a new data model is to be developed and implemented.

The following new hierarchical data model, resolving above mentioned issues, is proposed for discussion:

The flexible block design allows e.g. to visualize multiple simple groups of rooms, but also multiple schedules in parallel. GroupBlocks are always active, while ScheduleBlocks have defined start and end times, and in the user config a flexible start offset can be stated. A room's disabled and joinable attributes will then go hand in hand.

Evaluation of Implications

The current component tree can be found below (see Appendix).

The new Dashboard must consist of vertically separated blocks
→ similar to multiple groups in RoomGrid
→ for each Block (instead of Group) do:

• case block.type == "GROUP":
  create RoomGrid with GroupJoinCard (if applicable) and RoomCards as before
• case block.type == "SCHEDULE":
  for each Session do:
  • case session.type == "GROUP":
    create RoomGrid (as above and before) and position it within a GridCard as before according to the GroupSession's time and track props (since Sessions may or may not belong to a specific Track)
  • case session.type == "ROOM":
    create RoomCard (as above and before) and position it within a GridCard as before according to the RoomSession's time and track props

→ Large portions of RoomGrid incl. GroupJoinCard and RoomCard components can probably be reused.
→ The logic of positioning Rooms (and Groups) using GridCards from ScheduleGrid can also be adopted.
→ The logic of ScheduleGrid and its subsequent components can be included into the standard (RoomGrid) components as special cases to streamline the component tree (e.g. via if-else and optional component props or using external modules for non-UI functionality.).

In summary, much of the existing component structure can be adapted to the new data structure. At the same time, this will make the components even more complex in case the old data model is to be supported further on. To overcome this, a new component implementation should be favored, and a config file converter transforming an OfficeLegacy config into the new OfficeWithBlocks config must be developed to continue support for the then obsolete OfficeLegacy.

Appendix: Current Component Tree