-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
As a Sustainability apps user I would like to have a first MVP of the web-component implemented #1
Comments
Just a clarification: in the field "Organisationen" we expect to see the nr of organizations, by enlarging the details we just see here the nr. of organizations divided per type. |
Another comment: for the field "Teilnehmerranking" should not contain e.g. "Autonome Provinz Bozen". I would suggest here:
Please also include the possibility to scroll down the ranking. Also the search must be defined. What happens if no result is obtained? What happens if a research returns multiple results? What happens if a user then selects an organization? In this last scenario: ranking centered to the position of this organization, which is properly highlighted (e.g. other background color) in the ranking |
@Peter080202 I add also here the reference to the API calls:
These end-points retrieve only the last value. For getting the history, there is another API call (check https://swagger.opendatahub.com/?url=https://mobility.api.opendatahub.com/v2/apispec) |
Short summary of what we have agreed today with @Peter080202, relevant also for @danielecanu: First implementation iteration (next week - to be discussed during the meeting scheduled on 6.9):
Second implementation iteration:
|
@Peter080202 @danielecanu as agreed today, following points should be fixed in order to complete a first MVP with Suedtirol Radelt data:
We also decided to leave the organization filter out, since it is already possible to search in the ranking and select one certain organization. For the PR, it is probably better that you pull the application that we can then directly integrate and configure in the web-components store. Please include all relevant variables that can be set in the configuration of the web-component, including the "Challenge" |
@rcavaliere |
@Peter080202 at present it seems that we are importing only the data from the challenge 2024, but we are still checking the data flow. However the rule would be the following:
In generale, the latter method returns all available Challenge, you should distinguish the different "stations" provided here. You could use also a different API call, if you want to have just this list. |
@Peter080202 in the meantime, we have solved the issue with the data flow, now it seems that everything runs in a stable way.
With this call we have asked the data of the last three days (21.09 - 24.09) related to the KPI |
@rcavaliere , I just submitted the pull request for the first version. The PR doesn't include any logic for generating charts as I encountered an issue with the provided API. Since we are visualising data for e.g. Südtirol Radelt 2024, I believe it would make sense to call the endpoint using a start date of 2024-01-01T00:00:00.000Z and an end date of 2024-12-31T23:59:59.999Z. However, the API currently only supports a date range of up to 5 days. Could this limit be extended, perhaps to 31 days, so that we can at least fetch data month by month and aggregate it, resulting in 12 requests per year? Additionally, @danielecanu suggested that summing up the values for the entire year may not be the best approach, as we could be in July and Südtirol Radelt 2024 might only return data until June 2024, which will probably lead to a dent in the curve. He proposed that it may be more appropriate to draw separate lines for each action, resulting in x lines where x equals the number of sustainability actions tracked. You can discuss this idea further in the next meeting. Lastly, during our previous meeting, I mentioned an API issue where some organisations appeared twice (Marktgemeinde St. Lorenzen and Libera Universitá di Bolzano - Freie Universität Bozen). I've attached a screenshot showing the data for Marktgemeinde St. Lorenzen: Please reach out if you need any clarifications. Please also make sure to tag the developers who are taking over the project (@mathiasmader and @redek91). Thanks! |
@Peter080202 thanks for the feedback, we will discuss this. |
@mathiasmader @redek91 @danielecanu we have deployed the first version of the web-component here: https://webcomponents.opendatahub.testingmachine.eu/webcomponent/sustainability-apps I think we have some issues with the graphical elements, e.g. we don't see the arrow left and rights so it is everything a little bit ugly at the moment. Don't we also have a basic graphical layout for the entire web-component to be used? I kindly ask you to check this, you can refer to my colleague @clezag if we need to adapt something in our deployment. Apart from this, from a technical perspective everything is implemented as we agreed and the data is properly shown. One usability issue that I have currently seen is that if you try to select another organisation from the list in order to check the specific KPI associated to it, this is not possible. I would also like to have the possibility to not select any organisation at all and see the total KPIs. One additional feature which would be nice to see is the historical evolution of the KPI. Now that we have a stable data flow, we have seen that in the back-end the KPIs are updated once a day, i.e. we have an updated measurement in correspondence of each day. This means that we could simply draw some plots in the empty part of the web-component by just showing for each calendar day the correspondent value. The API call to be used to retrieve this is to be found here: #1 (comment) So by summarizing, before considering this first implementation iteration closed, I would request you the following:
Can you provide us an estimation for checking and implementing all this? We could also organize a short meeting if needed, or to better explain all these point or (if everything is clear) once a new Pull Request (PR) is made and deployed, so that we can discuss and finally approve all this and organize the next steps. |
@rcavaliere I already opened a PR for the graphical issues. #6 |
@redek91 thanks for the notice, we integrated the PR and now can see the graphical elements correctly. What about the overall possibility of personalizing the layout of the web-component? |
@rcavaliere I will make an estimation of the work for the display of the historical data. I think there is a misunderstanding on how the component is working right now:
We should organize a meeting with @danielecanu and @mathiasmader to clarify these points. |
@redek91 yes, I like your idea, actually we already discussed it. From an usability point of view, I think it's the best choice possible. |
@redek91 can we plan to have the organization filter view implemented this week? And maybe the plots with the historical data next week? Let me know about a possible implementation plan, so that we can have a first complete PoC |
@redek91 @danielecanu as agreed, let me summarize the list of modifications we agreed today:
This means that it won't be possible anymore to change among types, as actually the case.
Plan is to complete all these missing developments within week 47. After this we will concentrate on the possibility to apply a certain graphical layout to the web component in the configurator |
@rcavaliere I think we have a problem with the timeseries as it is right now if we want to show 1 value for each week. Currently the api gives us values over time for each of (km_total,co2,money_saved, number_of_people) per day. So if we want to get all data of the last year the formula is: We get 72.8 also we need 73 requests to get the whole year. Each request takes 2 seconds, also it would be Would it be possible to provide an endpoint that already provides such data?
This way the data would be aggregated on DB side, which is probably the most efficient way. Can we make a call to solve this? Please let me know. |
@redek91 I think this is somehow doable. We have for example this application (https://analytics.opendatahub.com/) with which we can see large timeseries of data without any particular issue. Check for example this API call: In your case you would have max 52 points per plot, so this shouldn't be an issue. Let's try to implement this, and then see how to eventually improve the performance |
@rcavaliere this data is only for 1 parking station, as soon as you remove the scode filter it has the same problem. It is normal it is a log of data. Is the day limitation only on the test env "https://mobility.api.opendatahub.testingmachine.eu"? Should we show the graphs only if an organization is selected? In this case the data would only be loaded if the organization is selected or changed |
Just chiming in, @rcavaliere this is related to our new history quota, which is only active in testing right now (production soon). You can raise the limit to 100 days by passing a In general, it's not ideal that a webcomponent would request lots of historical data and do the aggregation on every request. |
@redek91 I tested a little bit the new version of web-component, which you could also see (full screen) on https://webcomponents.opendatahub.testingmachine.eu/webcomponent/sustainability-apps In general, very good work! We are approaching a final MVP. I just report here some few minor cosmetic things, which should be fixed in order to a presentable web component:
Can you please fix these points and then make us a new PR? I provide you then a feedback for the visualization of more historical values. |
@redek91 very good, I think we can consider complete this very first implementation! |
Nice to hear that. Thank you for the feedback. |
@rcavaliere I still have problems with the filters, i will check after lunch |
Requirement: the filter "Sustainability Action" and "Organisation" should be considered even in the web-component and in the configuration of the web-component store.
Expected behavior:
Review of reference design:
240523_ConceptAPPReview_NOI.pdf
The text was updated successfully, but these errors were encountered: