Please, explain "Forcing"...
Btw, gorgeous graphs! Like the histogram layout in "Forcing" (although i think i don't fully understand it)
Thanks for not quoting the entire post - it vexes me greatly (insofar as anything on the interwebs is vexing) when people do that 
I'll just go over each graph real quick and go over that one a bit more in detail.
Estimated Hash Rate - Pretty much just that. There's two ways to measure this on most coins, but due to constant difficulty adjustment in Slimcoin, one of those methods would need a bit more work. Thus the method used here is to work back from the difficulty-per-block and taking an average, ditching any outliers using a pretty naive trim function. Good enough for an estimate anyway.
Fractional Difficulty - The difficulty, expressed as a fraction, as reported for each block. Again, Slimcoin adjusts difficulty constantly, so expect to see this jumping around pretty wildly, but with an overall upward trend (as long as more hashing power gets thrown at it anyway).
Min(t)ing - The amount of Slimcoins mined per block. The two mining methods - Proof-of-Work and Proof-of-Burn - can quite clearly be seen here, with PoB yielding higher rewards, but occurring far less frequently. There's also a small indication of the Proof-of-Stake adjustment events (don't ask, google 'proof of stake').
Older graphs also showed and a sum of the mined Slimcoins. This was moved to the Coin Supply graphs.Forcing - a pretty arbitrary measure of how the hash rate is affecting the difficulty. There's several ways to graph this, but I settled on this one due to the difficulty being adjusted each block.
If a block is found in half the time that is intended (the intended duration between blocks, for a coin with a fixed duration - for Slimcoin that's 90 seconds) to be found, then there's a 2x forcing factor. If a block is found in twice the time, then there's a -2x (actually 0.5, but LibreOffice doesn't seem to offer the appropriate graphing style when using fractions) forcing factor. Ideally they should all hover around +1 and -1, and all is well. Right now, a majority of them (not by much though) sit at greater-than +1, meaning hash rate overall is climbing.
( For Bitcoin, for example, this is pretty much the case since the last drop in hash rate due to market panic - ever since, the influx of hash rates has been greater than the adjustment (every ~2016 blocks) keeps up, resulting in difficulty adjustments every ~12 days, instead of the intended 14 days. )You might also see a few samples between -1 and +1 - these shouldn't be happening, as they're the result of the time difference between two subsequent blocks being negative. As far as I understand it from the Bitcoin network, the timestamp is pretty much supplied by the miner, and their clock is allowed to be off by some amount of time, which can result in block N being at time t, and block N+1 being at time t-x . Thankfully, these are rare
Though if the miner behind, say, Block 1400 could check that their miner is actually syncing with an NTP server, that'd be great as their clock is ~5-7 minutes fast 
The histogram just makes it a bit easier to interpret than the cloud of dots - it counts each value as it occurs between two whole numbers. The exact number isn't that interesting, the occurrence relative to other bins is.
Block size and Transaction count - Exactly what it sounds like. The least interesting graph (to me), other than showing a nice correlation with the beginning of Proof-of-Burn blocks.
Block Nonce - The nonce value used in each found block. When mining, the software basically starts at a given value, makes a hash, adds 1, makes a hash, etc. etc. until it's got one that yields a valid Proof-of-Work block (the nonce for Proof-of-Burn is always zero and isn't shown - mostly because you can'y have 0 in a logarithmic scale chart
). Don't worry about there being two bands, that's just due to the way the nonce loop works. I also wouldn't recommend trying to play the numbers game based on its display, the logarithmic scale can be deceiving - on a linear scale (the light blue dots in later graphs), it's a nice even distribution (within the confines of the nonce loop).
Block Height - exactly what it sounds like. For Slimcoin, this should be a nice linear line. You can see that in the early hours of the coin there's a bit of a wobble as there was a huge influx of hash rate, causing blocks to be found a lot faster than they 'should have', the network reacts, and it's been pretty stable since. In later graphs, this also shows the 'burnBlkHeight' ('burn height'), which is "the nHeight of the block holding the burn transaction", and so should appear fairly random (as long as people randomly burn coins, too) and always below the main Block Height line. Further graphs additionally show a 'clock error' indicator, for those blocks that have a timestamp that is half an hour or more off from what they should have been.
Exchange rate - also exactly what it sounds like. The exchanges haven't been up for very long yet, so expect these values to be...what they are. They'll settle eventually.
Coin Supply - (only in later posts) Shows graphs for some of the Coin Supply stats in the block chain, and derived values.
supply is the 'moneysupply' parameter,
burned is the 'nEffectiveBurnCoins' parameter.
mint sum is a combination of
PoW sum and
PoB sum[/s], which are the sum of all minted coins for each of the two block types. The difference between the mint sum and the supply is shown as mint-supply on the secondary axis. There's also a pink squiggly line that is probably best ignored, but essentially is the difference between i]burned and
PoB sum.
