FPL Player Value, Expected Returns and Targets

FPL players range in cost starting from 4 up to 13 so how do you compare them fairly across such a broad spectrum? What sort of returns should you expect from each price bracket? I’ve tried to apply some (very rough) maths to it to find out who’s justifying their price tag.

Season Target

Firstly, we need to set a points target for the season to get our weekly target. I’m going to base mine on equalling my best ever season, 2016/2017, where I scored 2281 points, with a rank of 16,876. So, for this, I’m using a season target of 2280 points, which as you’ll see further down makes the maths easier.

Scope and Disclaimers

The next thing is to set the scope of this exercise and get in my disclaimers. I’m assuming 38 “normal” game weeks with no hits and no chips. I’m also ignoring rises in team value. Finally, I’m giving all figures rounded to 2 decimal places.

Team Value

So, breaking things down, we all start with a team value of 100. This means each of our 15 squad players averages out at a cost of 6.67 (100/15).

Only 11 of our 15 score each week so we need to focus on the team rather than the squad. I’ve assumed that our first 11 have a cumulative cost of 82. That’s assuming a typical value of 18 on bench, something like 4.0, 4.5, 4.5, 5.0.

Using that total playing cost of 82, each player now has an average value of 7.45 (82/11).

Weekly Target

Going back to my season target of 2280 points. Over 38 game weeks this (conveniently) breaks down to 60 points per week. So, I have a weekly target of 60 points.

Player Target

The next thing to work out is the average return required from each player each week. Given that our captain scores double this is the game week requirement divided by 12, 60/12 = 5. So, I want each player to score 5.

Expected Returns

If I’m expecting an average of 5 points from an average player cost of 7.45 that means I’m expecting each player to return 0.67 of his cost in points. Roughly two thirds. So, a player worth 12 should return 8 points, a player worth 9 should return 6, you get it.

Value Index

We can then take this expected return number and divide by 0.67 to give a value index based on 1, where 1 is the expected value, above 1 is better, below 1 is poorer.

We can estimate the value over the season so far by looking at the Points per Match and comparing that with the cost. If PPM divided by cost is less than 0.67 the player’s returning lower than expected, if higher it’s better. This index makes it easy to see how much better or worse as a percentage. 1.14 = 14% better, 0.92 = 8% worse.

Real Examples

Here are some examples using stats from mid game week 28, 2017/2018 season.


PlayerCostPPMValue Index


PlayerCostPPMValue Index
De Bruyne10.46.40.92


PlayerCostPPMValue Index


From these few selected players in the examples, we can see that the best performing for their cost is Ben Davies of Spurs with 1.36; the worst is surprisingly Harry Kane with 0.74.


There are obviously other factors like minutes played but maybe we can use this value index to see which players perform consistently when selected. Maybe using point per match based on recent form rather than the season average would yield more accurate results?

Lightning Fast Filtering in JavaScript

I thought I’d share a technique for filtering large sets of data quickly in a web page. The scenario is a biggish set of data, 100,000 records, with each record having 3 properties, and we want to filter them using text matching.

Here is the finished article with dummy generated data. Give it a try. Just type any 3 or 4 characters and watch it do its thing.

See the Pen Fast Filtering with JavaScript by Chris Smith (@chris22smith) on CodePen.dark

Fast, isn’t it? You can go into the JavaScript tab and see how it all works but I’ll explain some of the main parts.

When trying to make it fast the most important thing to be aware of is that changing JavaScript objects is fast, changing the DOM is slow. So, we do as much as we can in JavaScript and then just update the DOM at the end. If you try to create 100,000 <li> tags it will be very slow and will probably die on you.

The first step is to set up a function to convert the data array into a HTML list. We keep this fast by setting a limit on how many items we will show. In this demo I’ve set it to 10 but even increasing it to 100 makes little difference to the speed. They key thing is not to get into big numbers which put a strain on the DOM. So we don’t loop through all the items, only the first few. A nice small loop, which runs quickly.

The building is all done in JavaScript, with nothing touching the DOM until we have a complete Document Fragment with all the list items ready to append to our list. I’ve separated out the building of each list item into its own function to hopefully make this even faster. Whenever iterating through large numbers of records the more variables and functions we can take out of the loop and pre-define the better.

The next step is to get the data array with the full data and filter it down into a smaller array using the native JavaScript filter() method. This method is incredibly fast, much quicker than using a for loop to iterate through each item. You can read more about filter() on MDN. If you use a predefined function with it rather than an anonymous function it’s faster still.

Once we have the filtered down array we can call our function to rebuild the list in HTML. It all happens in the blink of an eye.

As a final touch I’ve added a count message function which gets called each time we filter. This just helps to see what’s going on – how many records are being shown and the size of the reduced data set.

Accessible Colour Contrast

When I started looking at accessibility and using the aXe accessibility testing tool, one of the first things that it reported was insufficient colour contrast. So, I started looking into it. The page I tested had quite a few different shades of grey (not 50, before anyone else says it) so this seemed like a good place to start.

How light can grey text be against a white background, or flipped around, how dark does a grey background need to be for white text to be clear?

And the same with black. How dark can grey text go on a black background and how light does a grey background need to be for black text to be easily legible?

The results are shown in the embedded pens below. Please share if you find this useful. :)

See the Pen Accessibility – Colour Contrast with White by Chris Smith (@chris22smith) on CodePen.dark

See the Pen Accessibility – Colour Contrast with Black by Chris Smith (@chris22smith) on CodePen.dark

The next task is to find the acceptable contrast blacks and whites for pale greys, like #EEE or #F7F7F7, and dark greys, like #222.

What I Learned in 2017

A bit late but I still feel it’s worth keeping track…

2017 has been different to previous years. It wasn’t so much about learning new tech and tools as just getting back to basics and doing things better.

Simplifying Things

I’ve learned to keep things simple and not make them more complicated than they need to be. I actively try to write less JavaScript, doing more with HTML and CSS, and trusting native form controls instead of trying to re-invent them.

A good example might be something like a list of text items where we want the currently selected item to be bold. We could use JavaScript to set the style of the selected item and add click events to change the state of each item but we don’t need to. When we just look at the requirement and what is actually happening, it can be done with a radio button list. Just add radio buttons each with a unique  ID but the same name attribute. Put a label after each referring to it with the for attribute. Finally use CSS to hide the input and apply a style to :checked + label. Done. It’s a radio button list in disguise. Not only is it much simpler code but it’s accessible as a non screen user just sees a standard radio button list.


In the world of Angular, and starting to explore the more recent versions, I’ve got used to using components. As a front end developer/designer it’s been great to be able to build a small standalone snippet of HTML/CSS in CodePen. By having it small and isolated it makes it easy to test in browsers, linting tools, accessibility tools, etc. It’s like unit testing for functions.

Sass (SCSS)

I came to Sass very late but it hasn’t taken long for it to become the norm and writing standard CSS now just feels weird and like hard work.


In the last couple of months I’ve made a conscious effort to improve accessibility. I’ve started using aXe accessibility checker and guidance from the Accessibility Project site, It’s a big area and an important one so more about that in another dedicated post.


I’ve dipped my toe into the waters of cross platform development with Xamarin. It allows you write code in C# and export separate versions for iOS, Android and Windows. There’s still some platform specific quirks but it’s about 90% reusable and the framework makes it manageable. It now supports some CSS too as well as it’s own style rule syntax so should be easier.

Adobe Illustrator

Final one on my list is that I’ve now got Illustrator. I don’t really know what I’m doing yet, still Googling each new thing I need but it’s an amazingly powerful tool. It’s been great for creating alternate versions of logos, converting PNGs to SVG and optimising existing images.


I’m not sure what 2018 holds. I think I might actually start doing some training, focusing on HTML and CSS.

Native Browser Controls Rule

It’s become very common for designers to replace the standard native browser controls with their own custom controls. There are good reasons for this, consistent appearance across browsers and devices being the main one. However, there’s a lot more to consider than just how it looks.

Form Controls

Let’s think about something like a slider switch in place of a good old fashioned checkbox. It looks cool but…

Is it accessible?
How does it appear to a non screen user?

Does it have a disabled state?
And a read-only state?
And a focus state?
Do these states all also work for non visual users?

Can you tab to it?

Does it go back to its initial state using a form reset?

Does it work with touch gestures, e.g. swipe left to right?


Now let’s think about a simple link. It’s pretty common to see icons used with an onclick event instead of links. But its not the same.

How would a user know that it’s an interactive control? Maybe it has a hover state style change but this would not help a non screen user.

A link (a tag with href attribute) does other things. You can tab to it. On Windows, you can use Ctrl + click to open in a new tab, Shift + click to open in a new window, right click and “Save link as…” (or equivalent) to download the target file. Wrapping the icon in an tag opens up a lot more possibilities.

I’m not saying don’t use your own controls but before replacing native controls think about what you might be sacrificing and make sure you’ve got it all covered.