Advanced Event-Specific Insights

[phil-lopreiato]

As suggested here: http://www.chiefdelphi.com/forums/showpost.php?p=1546791&postcount=25

This extends Insights to events and allows us to calculate more stats at that level. We can also put this over a season.

---

Considerations

• We want our solution to be scalable over different seasons
• We want this to be easy to render on multiple platforms (if we do this right, we can finally solve our long-standing insights+API problem)
• Caching is important, so many clients don't duplicate work, slowing them down

Implementation

For now, we can just do calculations in the event controller and not store or expose them. But if we want this to be displayed on mobile (which we do), we'll have to improve on that solution and make it generic across seasons

• Do we just publish a list of key/value pairs and lets clients worry about rendering?
• How do we know how to render each thing. Do we pass meta-data about each key telling how to render it (percent, string, number, etc)
• Will this generalize across all seasons? What kind of thing would we calculate for other games, if we could?
• I don't want the app to have to do insight calculations, because it's slow, complex, and wastes computation. Do we build all this in the TBA API, or do we use a separate app-engine project or TBA module where we don't have to worry as much about data structures (where its only job is number-crunching).
• Since this is a community project, if people want other stats, it's reasonable to expect other people to submit PRs for future game-specific stuff, or use webhooks and run their own calculations

[nwalters512]

The alternative to making things generic across seasons is to simply to special-case rendering for each year on each client that would consume this. While this would give us fine control over how things look and let us account for very year-specific stuff (whatever that may be), it would require a lot more engineering time and coordination across platforms, the number of which we're supporting is growing each year. Moreover, adding a new piece of analytical data would require changes to each client, something that may not always be ideal (looking at you, App Store review times).

If we can find a way to represent data generically and describe how said data should be rendered, I'm all for it. However, I think we should look at as many games as possible and see exactly what kind of fancy analytics we'd want for each one. Once we have that list, we'll have a rough idea of what kind of data and rendering we'll have to support, and we can try to design a system from there.

[gregmarra]

Could we just allow clients to render arbitrary tables provided as key
value pairs by the server?

On Thu, Feb 25, 2016, 13:16 Nathan Walters notifications@github.com wrote:

The alternative to making things generic across seasons is to simply to
special-case rendering for each year on each client that would consume
this. While this would give us fine control over how things look and let us
account for very year-specific stuff (whatever that may be), it would
require a lot more engineering time and coordination across platforms, the
number of which we're supporting is growing each year.

If we can find a way to represent data generically and describe how said
data should be rendered, I'm all for it. However, I think we should look at
as many games as possible and see exactly what kind of fancy analytics we'd
want for each one. Once we have that list, we'll have a rough idea of what
kind of data and rendering we'll have to support, and we can try to design
a system from there.

—
Reply to this email directly or view it on GitHub
#1374 (comment)
.

[nwalters512]

Big tables of data work well on a desktop browser, but making that work nicely on a narrow phone screen is tricky. Which I guess is less of an "how do we serve data" issue than it is a "how do we display complex data sets nicely on phones" issue, which is something we'd have to figure out anyways. The other issue crops up if we someday want to display something beyond tabular data. I'd rsther design for that now. But if we limit ourselves to tables, that's probably by far the simplest solution.