Income tax rates are based on current/last year’s income. This makes them easy to calculate and implement.
This immediacy of taxes also makes them painful, and makes the tax slab thresholds as artificial barriers to income mobility. An example of this is when we get a raise which pushes us from near the top end of one tax rate bracket, to the bottom end of a higher tax rate bracket. This frequently means that even though the employer is paying us more after the raise, we are actually taking home less money due to a higher tax rate.
Government benefits work similarly. For example, the unemployment benefit / social support payments cut off (or reduce dramatically) when we start working. However, after accounting for taxes and loss of benefits, the take home income from pay is often lower than the unemployment benefits.
I had an appointment at the hospital today, and was thinking about the rates at the hospital car park. The parking area at big NHS hospital in my town has the highest parking rates around. They are probably more than double the rate at any other paid parking zone in the town.
At a first look, they seem extortionist. At most places, high parking rates are a nudge for users to either take an alternate means of transport, or to curtail their visits. At a hospital, however, few people visit by choice. Also, the visitors are more likely to use a car – comfort for the ill and all that. By charging these, probably ill, visitors these extraordinarily high rates, the hospital/NHS/council are just heartlessly milking the already suffering.
On a second thought, however, there is a valid reason behind these high rates – consumption tax. They are not just parking rates, they are an indirect tax on the heaviest NHS users.
The usual Premier league table gives a good idea of the ranking, but the gaps between teams aren’t immediately obvious1. I love how this visualisation shows both the rankings and the gaps with one simple line.
There are no visible cues hinting at ability to navigate from one expanded post to the next (or previous).
Navigating back to the post list (using back button), and then to next post makes it slow, and click heavy.
Keyboard shortcuts work, but there are again no visible cues indicating even their presence.
No visible hints that any keyboard shortcuts exist
Keyboard shortcut discoverability is solely by trial and error, or ‘Google’
Traditionally, pressing ‘?’ (in, say, GMail or Pocket) brings up relevant shortcuts modal. Doesn’t work in reader.
One suggested hint could be to place a keyboard icon next to the help (?) icon, at the bottom, in the left navigation bar.
j/k navigate to next/previous post as expected. However, the more ‘lay’ user-friendly left-arrow/right-arrow versions don’t.
esc key works the same as browser’s back button – navigating back through history stack (i.e. going back to last viewed post).
A better (expected) implementation would be to jump out of expanded-post view to the posts list view, ideally scrolled to the last viewed post.
Like keyboard shortcut, l, works as expected. Adding f as an additional activator would be useful – a lot of platforms use favourite as an alternative to like, and some users may be more behaviourally trained to press f instead of l
A minimal, no-frills blogging app with markdown editing2, inline tagging support3, and draft auto-sync4 to WordPress and Medium
I find WordPress‘ editor too cluttered (despite the distraction-free mode), and Medium‘s too fiddly-gimmicky. In fact, I write most of my posts these days in another Automattic product – Simplenote, and then copy it to my WordPress blogs, or Medium for final editing, formatting, etc.
My WordCounter Chrome app already supports Markdown Extra. Reusing that code, adding Medium & WordPress API support, and adding a #tag parser shouldn’t take long. The only question is do I care about it enough to prioritise it over all the other stuff that’s on the backlog?
For the last couple of months that I’ve had this idea, the answer has been no.