The Electoral College

Four years ago, Donald Trump heard that Mitt Romney was going to win the popular vote but lose the electoral college. This was not true, but never one to let facts get in the way of a good rant, he tweeted this:

"The electoral college is a disaster for a democracy."
Is anything NOT a “disaster” for this guy?

Now, four years later, we find ourselves in that exact disaster. Donald Trump, despite losing the popular vote by over a million votes, is going to be our next president.

Made aware of his hypocrisy, Trump tweeted this yesterday:

If the election were based on total popular vote I would have campaigned in N.Y. Florida and California and won even bigger and more easily
He would have won bigly, irregardless!

Here’s the thing – Trump has a point. It’s embarrassing that our 70 year-old president-elect is learning this high school civics lesson right now, on the cusp of his election, but he has a point.

Donald Trump won fair and square. We knew from the outset that the election was determined by the electoral college, and the campaigns planned accordingly. They spent all their time in the battleground states, and none in solidly Democratic or Republican ones.

But that doesn’t stop us from asking the question – are the rules fair in the first place? And how would the candidates have fared in an alternate universe where we chose the president based on popular vote?


According to the non-profit FairVote, electoral competitiveness is one of the main factors in voter turnout. When people think their vote won’t matter, they are more likely to stay home. In 2012, turnout was 9% higher in so-called “battleground” states than it was in non-competitive ones.

Based on this year’s estimated turnout numbers, that means at least 7.5 million people stayed home this year because they lived in a non-competitive state and felt like their vote didn’t matter*.

This is bad for democracy. When people think their votes don’t matter, they stop caring because they feel helpless. This feeling even affects voters that do show up, just to cast their vote for who they consider to be inevitable.

How voters would have cast those additional 7.5 million votes, we don’t know. Hillary is currently leading by about 1.5 million votes, so it’s definitely enough to swing the election. But its impact on turnout isn’t the only unfair thing about the electoral college.

Candidate Focus

As a candidate, you must win the battleground states. This is all that matters. So, issues that matter to battleground state voters are all you care about.

As a result, issues that are important to people who live in non-battleground states are completely ignored. This is something conservatives and liberals should be able to unite on, because it hurts us both equally. Wouldn’t it be great if candidates had to go to California and talk about tech policy, or Louisiana to talk about levees? With the system they have now, they have no reason to.

This reality probably helped Trump more than Clinton this election, because the battleground states have a much higher percentage of working class factory workers and farmers than the nation as a whole. Trump’s message resonated with this group more, and his more divisive comments were less of a dealbreaker for them.

Supposed Electoral College Benefits

Some supporters of the Electoral College claim that there are good reasons for keeping it around. People making these claims tend to be Republicans, which is mighty convenient considering they won twice in the past 20 years while losing the popular vote. But let’s examine them on their merits regardless.

The first is that the Electoral College gives more power to “small states.” Trump made this claim himself recently. Darrell Huckaby of the Newton Citizen made it as well, saying:

If we eliminated the Electoral College people in two-thirds of the states would be virtually disenfranchised when it came to presidential elections. All the time, money and effort would be spent wooing voters in California, New York and Florida.

That’s nonsense. California, New York, and Florida accounted for about 31 million out of about 135 million votes total this election. Even if a candidate won 100% of the votes from these three states, an absurd scenario, they wouldn’t even be half way to a majority. They would still need an additional 36.5 million votes.

Votes cast in 2016, by state

Electing a president by popular vote wouldn’t make candidates focus on larger states. It would make them focus on people in all states. Every person’s vote counts as much as every other person’s vote, and candidates would have to value them all equally.

A second argument for the Electoral College is that it gives a sense of finality to elections. Even when the popular vote is close, the Electoral College count is often lopsided by virtue of the fact that electors are assigned on a winner-take-all basis**.

I fail to see why that’s a benefit. If the election is close, we should know it’s close. It speaks volumes about a candidate’s mandate, and misrepresenting that mandate encourages extremism.

A third argument is that the Electoral College ensures that a candidate has trans-regional appeal. Slate writer Richard A. Posner makes this argument:

No region (South, Northeast, etc.) has enough electoral votes to elect a president. So a solid regional favorite, such as Romney was in the South, has no incentive to campaign heavily in those states, for he gains no electoral votes by increasing his plurality in states that he knows he will win. This is a desirable result because a candidate with only regional appeal is unlikely to be a successful president.

This is a repackaged version of the first argument, and it’s just as absurd. No region has enough popular votes to elect a president either. And they undermine their own argument with their example of Romney – he SHOULD campaign in the south, even though he’s going to win the popular vote there, because he could increase his share of the votes there and also speak to the issues that people care about there.

There are some valid arguments in support of the electoral college, like the fact that it simplifies recounts by sequestering them to individual states. But ultimately I am unconvinced that those arguments are sufficiently powerful to justify disenfranchising so many voters.


The obvious solution is to eliminate the Electoral College entirely and elect a president by popular vote. This would require an amendment to the Constitution.

Since that is difficult, some people have been proposing a hack. It involves states passing a law saying, “our electors will all vote for the winner of the national popular vote.” But the law will only kick in once enough states pass the law to total 270 electoral votes – enough to pick the winner. [Edit: it’s called the National Popular Vote Interstate Compact, and it has already has been enacted by 11 states totaling 165 electoral votes.]

As a computer programmer, I dislike the idea of implementing a hack to solve an important problem, but I also appreciate that sometimes hacks are an important stopgap measure in the interest of expediency. Hopefully once such a hack was in place, states would support the Constitutional amendment, and we could go back and do some Constitutional refactoring.


*Methodology: I used estimated vote numbers from the United States Elections Project, counting the totals of all non-battleground states. States considered battleground states were NM, VA, WI, MI, CO, PA, NH, NV, NC, FL, OH, AZ, IA, and GA. That’s right, I considered Georgia a battleground state. So my numbers are very conservative.

**With the exception of a couple states that divide up their electors by district.

“Pill” UILabel using IBDesignables

Apple introduced IBDesignable objects and IBInspectable properties to a lot of fanfare at WWDC 2014. In the demo, it was hailed as a major feature that would allow developers to create entire UI frameworks to brand their apps and give them a custom look and feel while still allowing them to design their UIs visually in Interface Builder. If you’re unfamiliar, here is a great NSHipster article about it.

Unfortunately, like a lot of Apple’s Xcode features, it was plagued by problems. Interface Builder has had a lot of trouble in the past two years rendering and linking such UI frameworks, leading to slowness and crashes. It still lacks obvious features like the ability to give custom names to IBinspectable properties and support for enums or other data types.

The good news is that it finally seems like it has stabilized a lot with Xcode 8 and Swift 3. So I wanted to give a demo of how to use the feature to create a common iOS interface element: a screen-shot-2016-11-10-at-11-27-57-am.


What is a pill label? We see “pill labels” everywhere in iOS – usually in table view cells, maybe calling out a number of unread items, or maybe a tag on an object. It’s a one-line label, with a colored background, and perfectly rounded ends. It’s like a rounded rect, except the radius of the rounded corner is such that there is not a vertical line.

“Essentials” pill label on the app store
Net News Wire app icon on the home screen, with a badge
App badges are pill labels

Getting Started

As ubiquitous as pill labels are, creating them is surprisingly difficult. You might think, “just add a background color and corner radius,” right? Unfortunately, there is more to it than that.

import UIKit

@IBDesignable class PillUILabel: UILabel {

    func setup() {
        layer.cornerRadius = frame.height / 2
        clipsToBounds = true

    override func awakeFromNib() {

    override func layoutSubviews() {

    override func prepareForInterfaceBuilder() {


This sets up an IBDesignable UILabel called PillUILabel. The setup() function applies a corner radius to the layer, and makes it half the height of the label itself to make the ends look round. Then we call the setup() function at various times in the view lifecycle – when the view awakes from a XIB file, when it lays out subviews (typically after a rotation or resizing event), and when it should be prepared for Interface Builder.

So if we add a label to a storyboard, set it’s custom class to PillUILabel, set a background color, and and set a text color, we get this:

UILabel with cut off rounded bacground
The label is cut off!

Since the background is within the view, it appears cut off. Clearly we need to make it wider so the rounded corners don’t touch the text. We could use autolayout to set a width, of course… but that means that we couldn’t set arbitrary text inside the label because it could be longer. We want it to be the normal, expected width of the label, plus a little padding on the ends. How can we accomplish that?

Intrinsic Content Size

Elements like UILabel have what’s called an intrinsic content size – in Swift 3, it’s a computed property named intrinsicContentSize. This is what we need to adjust. We have the ability to override this property and return our own value for it, and Interface Builder will use this value.

override var intrinsicContentSize: CGSize {
    let superSize = super.intrinsicContentSize
    let newWidth = superSize.width + superSize.height
    let newHeight = superSize.height
    let newSize = CGSize(width: newWidth, height: newHeight)
    return newSize

I’ve chosen to use the view’s height as the amount to increase the width by. Adding this to the PillUILabel will cause Interface Builder to adjust accordingly:

Rounded UILabel that is cut off on the left
Note – you will need to allow the Xcode project to re-build your code before changes will appear in Interface Builder.

This does what we set out to do, but there is still an obvious problem – the alignment. The text is not aligned in the middle of the label, it’s aligned left (the default alignment of UILabels). My preference is to just set the text alignment to always be centered in the setup() function of SympUILabel.

func setup() {
    layer.cornerRadius = frame.height / 2
    clipsToBounds = true
    textAlignment = .center

If you don’t want to do this, you could just set the text alignment in Interface Builder. But you’d have to do this every time, and if you are using intrinsic content size then you would never really want any option other than center alignment. So, once center alignment is set, we have this:

UILabel with rounded corners padded from the text

At this point, we have a pill label that can be reused in many applications. It will be rounded no matter the text size.

Going Further

Personally, I’d like the ability to adjust the pill label slightly to set a custom amount of padding on the sides and on the top. We can accomplish that by adding IBInspectable properties.

As the name implies, IBInstpectable properties are properties on IBDesignable objects that can be altered in the Inspector pane of Interface Builder. Only a limited number of variable types are supported, which you can read about here. In this case, we want to add two IBInspectable properties for vertical and horizontal padding that are GCFloats.

@IBInspectable var verticalPad: CGFloat = 0
@IBInspectable var horizontalPad: CGFloat = 0

Normally, I would advocate a more verbose name like verticalPadding and horizontalPadding, but if we do that, we get this in Interface Builder:

Screen shot of interface builder with cut off names of properties

Interface Builder attempts to derive the human-readable name of the property from the actual variable name, assuming camel cased variable names. And it severely limits the space they make available in the Inspector name for your variable names. These are two examples of where I think Apple has really dropped the ball on providing useful tools to us developers. The label for the property should be way bigger, and there should be some way in code to specify an alternate display name for the property, perhaps through headerdoc comments. But I digress. Back to the example.

Once we have created the IBInspectable properties, we need to implement them in our override of the intrinsicContentSize property. This is because those variables should alter the intrinsic content size of our label.

override var intrinsicContentSize: CGSize {
    let superSize = super.intrinsicContentSize
    let newWidth = superSize.width + superSize.height + (2 * horizontalPad)
    let newHeight = superSize.height + (2 * verticalPad)
 let newSize = CGSize(width: newWidth, height: newHeight)
    return newSize

Once we update this, we can head back to our storyboard, let the code re-build, and start interacting with our view!

An animated gif of the final label
Interacting with the final product


As of Xcode 8.1, there seems to be an intermittent bug with embedding these pill labels in stack views and then adjusting the intrinsic content size. It sometimes makes the pill view take over the entire stack view in Interface Builder (although it works fine at run time). I can’t seem to duplicate it consistently, but please post in the comments if you see this, or any other problems.


You can download or clone code for this project at github.