Closed piotrhomola closed 6 years ago
At most we can display number of active users in the last 24h. Anything more would require extensive processing. Shall I proceed?
Let us discuss a bit. I understand that you do not question that the idea is good, you only say that the computing would be too heavy, right? Then is that an "absolute" statement? I mean really nothing can be done the help meeting the requested display need? Maybe you could propose some intermediate solution that at least partly meets the display need and satisfy affordable computing requirements? Maybe some "expire date" column, or less frequent update of the statistics, or separate data base for the last 24h? On this occasion I also propose that for the next difficult issues we have some additional labels to better name the difficulties, e.g. N: requires redefining the technical assumptions for the service, D: heavy development effort required, Q: questionable (discussion, consulting needed before implementing).
There are a few issues with this proposal:
I do not think you have answered my question. "basic stats functionality" - I ask for nothing else but basic stats, we probably do not agree about definition of "basic", we started a discussion during the meeting but apparently we need to talk more. I agree that more complex things should be handled by a separate app, once I make an issue and it is rejected i find it insufficient to hear about too demanding processing. I'd prefer to be sure that there is no way to overcome the difficulty, any compromise or alternative solution. That is why I proposed more labels, to get better information, and better information is crucial to take decisions essential for the whole project. So in this case I want to be sure that there is no technical hope for any solution within the "basic" assumptions that help users to get more active by showing more dynamic ranking. That is also why I asked about your ideas to help going in this direction, you know by far better than me what is technically affordable, but let me repeat that apart from technical perfectness we also need to be user friendly and functional, there is and there always will be a fight between these two points of view - and we need to learn how to reach compromise. We have the "minimum display concept" or "trailer view" and I'm asking whether you have any ideas that would bring us closer to "last 24h stats" or not. If you classify the request as N+D+Q then I'll not be pushing anymore, but it would be great if you could keep your technical creativity active to support the merit of the project, in order to look for compromise solution that would not require increasing computing time, for instance what if we re-consider the processing performed now, maybe give up some operations that were useful until now but might be less needed with the dynamic ranking. I insist not for the pleasure of discussion, I just think the current display is below the minimum, not yet the trailer view. And please also keep in mind that the requirements for the trailer view will be changing anyway, for instance because of some new detector types joining the system, so we must be prepared to adjust the system accordingly, to add new features but also to remove or modify the old ones if necessary to keep the processing reasonable.
Not feasible with current architecture and resources.
We have on average 50 active users and 3600 registered, 1500 displayed with the current filter. I propose displaying only the users active in the last 24h, only with the updated app. It will make the ranking more dynamic, encourage the users to update and hopefully also to detect more often.