Season-Independant Date Range Statistics & Comparison

[patrickjmcd]

It would be great to be able to pull season-independant data. For instance, I know that Lance Lynn has a great ERA in the first few months of the season, tapers off during the middle of the season, and then gets hot again around late-august.

I think it would also be really neat to be able to see that data side-by-side (e.g. Lance Lynn in April-May vs June-July).

This is an AWESOME project. I started doing this exact thing on my own before I realized that y'all were doing it WAY better than I was. I'll be glad to help out where I can.

[kruser]

Welcome @patrickjmcd! Thanks for interacting here and creating some new discussions. Keep it up please. If you're wanting to submit code, check out the dev guide and let me know if you run into any setup issues.

For this specifically, a mockup might help me and others visualize your idea. A picture of a napkin sketch is an acceptable mockup ;).

We also need to start thinking more about the site's UX as we add features. Jamming too much data into these two tabs will be bad. I want to make sure it all flows naturally. I'll take on thinking about that part.

[patrickjmcd]

I just did a quick inspect/edit and mocked up this... Definitely would need some UI tweaking, especially since it ruins the charts.

A button on the filter panel would effectively cut the stat panel in half and add a new filter. Maybe that creates a tab bar above the filter panel to change the filter for each part in the stat panel.

[kruser]

What browser is that? Your Date Ranges are empty for some reason.

So you're wanting to do comparisons - I'll think about this as a general thing, stashing/stacking a current view. I don't want to recreate what browser tabs are for, but I can see would be nice to see several different splits together and not necessarily just for a single player.

[patrickjmcd]

I'm using Chrome. I didnt change any of the source files, just did "Inspect element" on the page and changed the HTML

[albertlyu]

Showing two different atbat views or pitches views with different filters to do comparisons would be a nice-to-have. However, the amount of horizontal real estate of the webpage that will be taken up may require a redesign of the views. Not every desktop's screen has 16:9 aspect ratio :)

Is it possible to overlay views on top of each other with two different sets of filtered results? That could save space horizontally. I could draw up a mockup if my question doesn't make sense.

[patrickjmcd]

That might make a bit more sense. something like this?

[kruser]

Yeah, I like that. We can use some sort of "sticky" button to stick a current filter.

My fancy progress bars for the other stats are getting us in trouble on that though. We can't replicate those, even though they may be more interesting that the line items you show above.

If you were only interested in the items you show, we could add a checkbox (like on the pitches tab) to each row, and when a row is selected it informs everything below it. Not great, but very obvious anyways.

Open to other suggestions too.

[patrickjmcd]

I tried to do the same thing with the progress bars and it wasn't working out so great. Once I spend some time working through how the site works, I'll be able to give it a real shot.

[albertlyu]

@kruser, it looks like my Date Ranges are empty too when I load pitchfx.org in Chrome. But in Firefox and IE, the date ranges are shown by default as expected. I cleared the cache in Chrome, and the issue persisted. @patrickjmcd, do you see the same issue?

[kruser]

I can confirm the issue with the dates. I'll fix it tonight.

[kruser]

@albertlyu and @patrickjmcd, I'm attaching a mockup of a more general ability to save your filters and quickly access them. It's not quite the same as being able to plot tables side-by-side, but it offers a general filter save mechanism that could be utilized on any player card.

Thoughts?

[kruser]

Another extension to this would be what @patrickjmcd was thinking, where we continue to show all past filters in the table data, as text-muted.

This might mean moving the % stats from the progress bars into their own table row though. Although I'd hate to get rid of the animated progress bars but maybe it is necessary here.

[albertlyu]

Perhaps a jquery knob could go in place of the progress bars? http://anthonyterrien.com/knob/

Edit: An animated widget visualizing the progress bars is great, but I wonder about the benefit of being able to visually compare the hitting metrics against one another. For example, even though wOBA is scaled to OBP, it doesn't necessarily tell me much that Morneau has a higher wOBA than OBP, other than perhaps he gained more of his wOBA linear weights from power perhaps. The progress rows are great for switching between filters though and seeing the relative wOBA values, for instance. Either way, a jQuery knob / dial or something like it can solve your vertical space issue, as you can store all six knobs in one table row, and stack them on top of each other for multiple filters without significantly increasing the web page's height too much.

A great option would be to overlay the progress bars on top of one another, perhaps Filter 1 can be transparent red, Filter 2 can be transparent blue, such that the overlapping bar is purple...?

[albertlyu]

For the last paragraph in my last comment, something like this, with more palatable colors:

[kruser]

Just say NO to jQuery! :)

I'm sure we could get an AngularJS knob though too. Both are interesting suggestions though. Let's keep churning on these ideas as I definitely think when we swap a filter we need to compare the wOBA, BA, OBP, etc. We could possibly just remove the bars in favor of a table once you swap the filter or save a new one too.

[kruser]

The most I think about it, the more I like keeping the progress bars, but morphing them into a table once the user picks another saved filter or saves a new one. That way this screen stays fairly visual when you first come to it, and only becomes table driven as you stick more filters on.

I'm going to assign this issue to me to work on over the weekend. Keep the comments and suggestions coming.

[albertlyu]

Sounds good to me. Just figured that if you're changing between one filter and multiple filters views, you'll want to keep the main view somewhat consistent, if possible. But it also makes sense that a multiple filters view is somewhat limiting because of the amount of additional space needed on the webpage. So it might make sense to convert the progress bars to a table when switching from a one filter view to a multiple filter view.

[kruser]

FYI, I didn't make any progress on this one over the weekend. I'm still working on the heatmaps.

[kruser]

I've started this work inside the issue-46 branch if anybody is interested in following along.

[kruser]

I merged a bunch of code for this from my feature branch and deployed it to the site. Note that the new filter results are maintained on the at-bat tab right now but not on the pitches tab. I'm thinking about doing the same thing on the pitches tab, with a rollup for each filter result. Clicking on a rollup would expose the per pitch-type that we see today. Let me know if you have any feedback on this before I get rolling.

Here is a screenshot of the new filter pinning feature.

I automatically have it create filters for the past three years if the user has no filters. And all of this uses local storage. I didn't test on a browser that doesn't support it. Sorry IE9 users, you're out of luck.

[albertlyu]

This is so slick! My initial suggestion would be to add other 'groups' of default filters beyond year, such as handedness, runners on base, first pitch vs. behind in the count vs. ahead in the count, etc. but this is so so slick so far. I noticed that you have to click around to get used to how default filters vs. saved filters populate and such, but I'll do some more testing this week to narrow down what I find intuitive vs. what I might find confusing. Otherwise, this is absolutely great work, though I'm sure the pitches view, particularly the heatmaps will require some thought before implementing. Good stuff.

[kruser]

I'm going to close this issue out since we have fufilled the original purpose. Let's tackle the pitches tab in the separate set of work since it requires a bit more though. I believe we should do #65 first though.