Usually, you want to do this to estimate a fee before sending a transaction. Transaction fees are way more complicated than they probably should be. I'll stick to calculating the transaction size here, but keep in mind there's more to the picture when talking about fees.
in is the number of inputs, and out is the number of outputs. If you haven't seen this discussed before, here's a crash course.
Using a block explorer you may have noticed that some transactions use multiple inputs, even though only one address is spent from. For example:
Bitcoin is an "electronic cash system". Understanding this concept is probably the most important thing you can do as a Bitcoin user. Unfortunately, it's the part that most beginning users skip.
Rather than physical tokens like metal coins and paper banknotes, Bitcoin uses electronic tokens. There's more here: Bitcoin: Think of It as Electronic Cash.
In Bitcoin, there's a useful relationship:
coin ≈ unspent output
Think of a transaction as a box. On the left are inputs. On the right are outputs. Each input links to the output of a previous transaction. An output can only be spent once, and it must be completely spent. An output with no later links to it can be spent, and is often referred to as an "unspent coin".
Each input in a simple Alice-Pays-Bob transaction contributes ~180 bytes, if you're using uncompressed public keys, and ~148 bytes if your public keys are compressed.
So, to estimate the size of the transaction in bytes, you need to know how many coins will be spent, and whether your public key is compressed or uncompressed.
Unfortunately, "consumer friendly" wallets won't show you your coins. You'll have to use a more advanced tool that supports "coin control" to do that. Bitcoin Core and Armory support coin control, as does Electrum to a limited extent.