One thing that the new framework for the front end is going to provide is an easy ability for me to build an API. I'm on the fence still about whether I should do something like that and make it public, I want to avoid giving people who can use something like that in unfair advantage, but at the very least I would give the data committee access to it, and if I did decide to make it public I would seek their guidance about how to roll up ways to use it as part of the actual application itself so that non-technical users would have access to the same analysis. But it's a bit early to be talking about that at this point, I just wanted to throw that out that this is one of the reasons I'm focusing on the new UI framework.

FWIW I'm willing to share my python script (it's ugly and simple) that I use to download all the csv files for a league and sql scripts that I put into a python library as examples of anyone wants to build their own sqlite database.

Unless we're giving feedback on a new engine version for testing purposes, I don't see a reason to give API access to only a select few.

Your concern about non-technical users lacking access to the same data that technical users is valid, though an API would actually alleviate a lot of that. I have a method of easily obtaining large numbers of game logs that I spent a lot of time automating.

An API would not only lower the "price of admission" to analytics (in reducing development time and technical skill in obtaining large amounts of data, hence increasing access), but also would re-level the playing field, since the few of us who actually have an automated system would have to re-create that part of the process.

An API could also reduce bandwidth usage for those running analytics, since CSV flat files (how game logs are sent) are notoriously inefficient space-wise. For example, a regular season's worth of game log CSVs takes up 25-35 MB of space, while the same data in a Feather file takes up only 10-11 MB (more on Apache Feather: https://arrow.apache.org/docs/python/feather.html; there are other methods that give even better compression ratios and could allow an entire season to be downloaded somewhat seamlessly, Feather is my preferred balance of IO speed and compression since it was designed with tabular data in mind).

There are also a lot more efficient ways of arranging the data in game logs too that would be better with an API. For example, if #2 John Smith was in the WR1 slot for a play, it takes 20 bytes to store that information ("#2 John Smith - WR" is 20 characters including quotes) -- the longer the name/number/position, the higher the bytes used. But storing a player id and then a separate player file containing id, name, position, etc., (which probably already happens on the backend) would considerably cut down on the overhead.

Opening up an API would also help people who might be willing to build tools for the community. I imagine there are more than a few owners who fall into that bucket (including me, potentially).

Nerds.

Thanks for all of the work you all do. I'm too lazy to deep dive data like you do, and if no one did what you do the game and its community would be far worse off. Also, hats off to all of my fellow slackers who never had Flat Zone or FB Dive in the playbooks because we were too dumb to figure out that they were insta-wins. We're the real winners here.

Same here. No time or patience to deep dive into the numbers. May have something to do with a not-so-analytical brain too. I checked my playbook when this whole thing started erupting and found I didn't even have the OLB Flat Zone available to me! I probably wouldn't have been adept enough to exploit it anyway. :)

Analytics is literally my job (in a different industry), but I grew up playing football through high school and have followed the NFL for 30+ years, so I have a deep love and understanding of the game.

Nerds like me are adept at finding extremely efficient ways of taking thousands (in my case, over a million) plays and using that data to find plays that work the best both overall and in certain situations.

Cool, been playing a while, always ****, great, found out two plays are OP, I might win now!

Narrator: Removed.

Oh *****.

If something needed removing then so be it. It's clearly a data driven decision.

*takes FB out back and shoots him*

With regards to an API, I think it's an excellent idea. I get not wanting to disadvantage non-technical people but from experience, I've found in other games people tend to publicly release their applications. I personally wouldn't; code I write is generally more theoretical (and never fully finished) to learn some more tech in the Java eco-system. It's never as polished as I'd like and tbh nothing I've written is unique to my coding kung-fu, can easily be worked out in spreadsheets - most of my ideas tend to be protoyped in LibreOffice.

Was thinking JSON for language independence but reading about Apache Arrow, it seems impressive for big data. From a Java perspective, examples I've seen don't appear to be as clean as you'd expect from JSON solutions, but then Python is used by hackers ;). Would arrow be appropriate for the use case of you logging in, wanting to download upcoming draft data?

The question is what functionality the api would provide. One game I used to play had a second "shadow" account created. This was read-only in nature, so any apps accessing it couldn't go in and trash the game for you. Another required third party app writers to register and gain a token for data access. Designing a good api is an artform, it should imo follow RESTful guidelines consistenty.

It also bears mentioning that irrespective of a public acing api being available, it'll always be possible to get data by logging in automatically and simulating the request, processing returned data, data a browser would receive.

It's a tough one. Much as I'd love a third party app so could get data, do analytics, send gameplan in would that damage site analytics as now accessing via phone / browser or would a login to the api server count? I suppose that removing the need to log in also loses the social side of things.

EDIT: Noticed earlier reference to a data committee - should the API be part of that or a sub-committee? Not everyone is at the data analysis level of settherick and others, for me data should drive decisions that affect things in game whereas api should foster the environment for people to make tools that can drive analysis, a distinction for me.

Safe to say this gets the "MFN Thread of the Year" award at the MFN version of the espy's...... The Mespy's?

When this move was made, JDB should have also removed the 3-4 Cover 1. It's as effective and less vulnerable than the FZ was.