Design breakdown

[ZorckMaster]

Break down the current design in smaller tasks to be able to start implementing them.

[ZorckMaster]

Added a docx file with some tasks for the design breakdown.
It is not a final version so comments, modification requests are welcome.

Sormas_design_breakdown.docx

[ZorckMaster]

Please consider that all the tasks are based on dummy data until we can't use real data for any reason.

[laurentiustanvitagroup]

The tasks suggested look great. I've grouped them under epics / stories as to facilitate and give more transparency

Sormas Angular Upcoming backlog items.pdf

[alexandrudanpop]

Please consider that all the tasks are based on dummy data until we can't use real data for any reason.

Hey @ZorckMaster, thanks for the document. Will also look into it. I just want to mention that we can use real data that is filled in the actual app - https://test-de1.sormas.netzlink.com/sormas-ui/ . This data should be available from the APIs. Our project is using https://test-de1.sormas.netzlink.com as a back-end, so any data that is on that test environment should be accessible to us as well (provided there are valid APIs to access it).

If you want to study the API - you can take a look here:
https://github.com/hzi-braunschweig/SORMAS-Project#is-there-a-rest-api-documentation

[ZorckMaster]

@alexandrudanpop Yes, I we can, but would like to mention that from the breakdown's perspective it is not the most important thing where the data is coming from that's why I said Dummy or from API. So we can do it either way, just need to have the elements of the design ready, then we can still focus on how we get the data. Of course we can directly use data coming from the API, no problem. I thought this is a secondary problem. If not, I can correct the doc where I said dummy data, it can be data from API.

[alexandrudanpop]

@ZorckMaster yep the data should be from API always - we have already the API client and all the fields should be mapped from the API responses. This adds of course extra complexity that we need to factor in.