lfaucon
commented
6 years ago This makes me think that we should change dashboards into activities. You want to be able to reuse dashboards and this is all what our activities are about. For example we should have a "count" dashboard which we can configure with the type of a log. If you look at the type and the implementation of dashboards, they are pretty similar to activities; Both have initial data, merge function and a viewer/runner. They get the real time data from the activities through the logs in the same way that we use the streamer for activities. Furthermore we have seen in the UNIL scripts that the professor might want to show the dashboard to the students for debriefing and that is something we want to represent in the graph as it has a pedagogical meaning, so dashboard will have a place both on the back office plane and on the classroom plane.
yandim
Currently, each activity can provide a single dashboard component (which can have multiple dashboards and visualizations). This provides a lot of flexibility, but it also requires a lot of code for things that are often very similar - which also leads to most activities not having dashboards, even for representing very simple measures. We have made some attempts at generalizing some code, with the
CountChartinfrog-utils. I suggest thinking about extending this approach.Could we come up with some kind of ontology of activity visualizations (this might already exist within LAK?). Off the top of my head, we can represent:
Most of the dashboards will probably be quite simple line plots, dot plots, histograms etc over variables related to things above. We have some special dashboards, but these can be categorized as above:
What I'm trying to think about is whether it would be possible to have a much more generic generation of dashboards. Would it be possible for an activity to simply mark certain variables as interesting, and whether we care about count/average/events per minute, etc? This is similar to how many server monitoring tools do it (for example CPU load should be an average over time, whereas server crash should be a count, web access should be an average count per minute etc).
The idea is to have a few objects that quickly define the relevant variables, their semantic meaning and how to process, and automatically generate dashboards from this. This would mean that it would be trivial to add dashboards to all the activities (very desirable), and we could also make the automatically generated dashboard more sophisticated, for example making it easy to see a certain indicator both as an average for the whole class, per group, see outliers etc - things that we would currently have to implement for each individual activity.
Of course, we would still enable custom widgets for very specific visualizations. (Although word cloud could probably also be generalized - many activities will have some kind of textual content).
It would also be interesting to look at approaches to xAPI recipes, as we begin embedding more external activities. For example, if it turns out that all quiz activities have similar log messages around how many correct etc, we can also automatically provide dashboards for embedded H5P/etc activities. (And we can use this for external logging/xAPI statements from embedded FROG activities).