Why I’m Leaving Facebook

The costs associated with the free social platform are just too high

There is a point beyond which a service becomes too expensive. The latest round of news about Facebook has made it clear to me that we have passed that point. The social impact and privacy costs of Facebook are too high for me. So, at the end of this month, I will be deleting my Facebook and Instagram account.

I’ve read many people lately who are making the same decision over concerns about how much social media dominates their time. Although that is a serious question, this is not my concern with Facebook. In fact, the app hasn’t been installed on my phone for months. I am deleting my Facebook and Instagram accounts because of the clear record of Facebook’s violation of the public trust. They know more about me than any other organization in the world. And I don’t trust them with that knowledge.

My goal is not to make a convert out of you. I’m not looking to spark a boycott or any sort of public demonstration. This post is to explain my thinking and maybe prompt you to think about your relationship with this company. That is all.

The issue I have with Facebook is cut and dried: They know too much about us (even if you don’t have an account), and they lie about what they do with that data.

Over the course of 2018, we learned a lot about how Facebook really operates, and it generated numerous scandals. Not only does Facebook follow you all over the web, track what you read, watch, and listen to, they also know what you purchase, where you go, and who you hang out with. Facebook has built a surveillance infrastructure that rivals in reach and depth anything George Orwell or the CIA could have dreamt up. And they have convinced us all to willingly hand over this information. Every day, millions of people share private and intimate details of their lives with this company.

The surveillance is not even the worst part. What’s actually worse is the purpose for which they use our private data. They are not using it to identify terrorists, study social ills, or encourage a constructive conversation in the public square. They are not aiming for any number of controversial, yet arguably defensible goals. No, they are using it to sell us T-shirts, insurance, and rugs. And of course in the process they are actually contributing to many of our societal ills. Smartphone addiction, a poisonous political discourse enflamed by filter bubbles, and foreign interference in our elections are just some of the problems that are being made significantly worse by Facebook. And in the last few weeks we’ve even heard about how they police political speech on their platform, with no transparency.

In tech punditry circles there was a popular phrase for a while that said if you used a service you didn’t pay for you were, in fact, the product. That’s not exactly true, but it does broadly capture the strategic reasons behind the success of companies like Facebook, Google, and others. My private data and ad impressions are Facebook’s inventory. I am their product. And that reality is one I can no longer abide.

By willingly handing over private information to these companies for a free service that is not essential—especially services that can be so destructive in how they can capture our attention—we are opening ourselves and our culture up to potentially massive problems. What we have seen with the Cambridge Analytica incident, Russian interference in our elections, and other Facebook scandals is just the tip of a very, very big iceberg. And I don’t think they can change course.

So I’m getting off the boat.

If you would like to keep up with what I’m doing after I leave Facebook, the best ways are to follow me is on Micro.blog, Twitter, or by signing up for my email newsletter.


Why I Switched to Jekyll from WordPress

This post is the first post on the new version of this site. If you are a regular reader then I’m sure you noticed the much cleaner and more mobile-friendly design. But what you probably didn’t notice—unless you routinely scrutinize URLs—is that this is now a static site. I left WordPress.

Now, for most readers of this site this won’t matter at all. Load times will be much faster, but it wasn’t noticeably slow before. Other than that, moving from a dynamic, server-side site to a static, HTML site won’t make one bit of difference to you. But it does to me.

WordPress is not terrible. But it’s not good, either.

Since I started blogging in 2003, I’ve used almost every major platform. Blogger, WordPress, Squarespace, and then WordPress again. I’ve never been happy with any of them, really. So when I started my tech blog last year I wanted something different.

For that site I chose Jekyll. Jekyll is a static site generator, not a blog platform, per se. Using text files written in Markdown, Liquid templates, HTML, JavaScript, and CSS it generates my whole website in a few seconds. From there I host it on Amazon’s S3 for a few cents a month. Last month it cost me just under $.50 to host and serve the site.

Once I got it in place it worked perfectly. Pages loaded super fast, I could customize the site using the tools I’ve used for years as a web developer and not some janky themes or plugins. I was able to create a clean, readable, and responsive site quickly and host it cheaply. After using Jekyll for just a few months I began work converting this site to Jekyll today. This post is the first on the new site.

For me, the decision was easy. I went with Jekyll for 5 reasons:

  1. I first went with WordPress to use some fancy, SEO-optimized themes. The theme(s) were not worth the money
  2. Beyond those themes, all of the “features” of WordPress were not only unnecessary, they made it harder for me to create the kind of site I wanted. The platform is overgrown and cluttered with features that don’t add much discernible value
  3. I don’t need to post “on-the-go” from my phone
  4. I do all my writing in Markdown, and WordPress did not offer an acceptable workflow for it. Yes, even with the fancy plugins and Markdown “integration”
  5. Finally, and most decisively, I had the technical skills to code my own site

This last reason is why most people will not be able to make the same choice I did. Even with great guides out there like the one I used, implementing a custom Jekyll site is still beyond the average blogger’s reach.

But I think static sites like this one are (or should be) the future for most independent writers on the web. Depending on your business model, there are very few downsides. If you need a membership site or other server-side features this would not be a good choice, but otherwise static sites have huge advantages.

I’m not making a living off this site, so I don’t have those needs. So with Jekyll I can run this blog cheaply, easily, and it fits right into my existing writing workflow. It really is perfect for me.


→ What the iOS App Store needs is better search

Bloomberg reported that Apple has a team working on monetizing App Store search, ala Google ads. The idea is that developers could pay Apple for better placement in user searches. From the story:

Among the ideas being pursued, Apple is considering paid search, a Google-like model in which companies would pay to have their app shown at the top of search results based on what a customer is seeking. For instance, a game developer could pay to have its program shown when somebody looks for “football game,” “word puzzle” or “blackjack.”

Paid search, which Google turned into a multibillion-dollar business, would give Apple a new way to make money from the App Store. The growing marketing budgets of app developers such as “Clash of Clans” maker Supercell Oy have proven to be lucrative sources of revenue for Internet companies, including Facebook Inc. and Twitter Inc.

John Gruber has it right:

This sounds like a terrible idea. The one and only thing Apple should do with App Store search is make it more accurate. They don’t need to squeeze any more money from it. More accurate, reliable App Store search would help users and help good developers. It’s downright embarrassing that App Store search is still so bad. Google web search is better for searching Apple’s App Store than the App Store’s built-in search. That’s the problem Apple needs to address.


Quick Grades v. 1.0

Today I launched my first independent software project, Quick Grades. Quick Grades is a free easy grader iPhone app built for teachers. I created this app for my wife several years ago, and I kept it updated for her. This fall I rewrote it from scratch for iOS 8. My wife, the original tester, loves the app and uses it often—and my hope is that many other teachers discover it and feel the same way.

I will post more of the technical details later, but I want to give you a short overview of the app. For those of you who aren’t teachers, let me introduce to you a tool that nearly every teacher in America knows well, the EZ Grader.

A vintage cardboard EZ Grader

This tool allows a teacher to set the total number of points for an assignment, and then quickly refer back to it to get the correct score for each graded paper. These graders have been around forever. I remember my mom using hers in the early 80’s, and it is the same one that’s sold today. It’s a useful item for teachers, but it’s also one more thing to keep track of.

Many teachers now use apps instead of the old physical EZ Graders. It makes perfect sense, but most of the apps aren’t very good. The one I my wife used before was not user friendly. The font was hard to read, the color scheme was distracting and hurt readability, and it did not have sensible settings or options. After watching her struggle with the app one too many times, I decided to build her a new one.

After three years of updates just for her, and all the changes from iOS 5 through iOS 8, the app evolved quite a bit. The functionality never changed, but the simple premise of this app offered lots of room to experiment and find the right design.

A four column design with a scrolling table for the scores turned out the be the right approach. Other applications jam too much information into one view. The choice to use a scrolling table view allows for larger and more readable text, and scrolling to find the right score is intuitive and fast.

The second major design choice was to allow the user to decide exactly what columns they want. Every teacher likes to see a different view based on their grading systems and preferences. Allowing the user to remove certain columns from the view also improves readability.

Additionally, I made the easy decision not to interrupt my users and ask them to rate my app. This is a topic that has generated a lot of conversation in the last year, and I land firmly in the ‘anti-prompt’ camp. Yes, App Store ratings are important. Yes, I really do hope my users like the app enough to rate it favorably. But no, I will not be interrupting their work to ask them to do so.

This app is small and focused. It’s simple by design, and a perfect use case for a mobile app. Your phone is always with you, so you don’t have to keep up with the old cardboard EZ Grader. On a phone the simple interface is better than a more complicated one. Clean design and a focus on the user’s needs yields a simple, yet very useful app.

That’s my hope for every teacher that downloads Quick Grades—that it makes their work just a little bit easier. Our teachers work so hard, for so little pay and have many challenges in their way. If I can help by adding something to their toolbox that is just a bit better than the alternatives, then I will consider this project a success.

Quick Grades is now available for free on the iTunes App Store.


For New Projects, Swift or Objective-C?

In the coming days I will be launching a new app on the App Store. I built this application for my wife three years ago after watching her use another app to help grade papers. Because of my employment at the time I could not release it, but now I will be doing so.

This fall I rewrote it from scratch in Swift for iOS 8, and I really enjoyed it. Learning Swift, the good and the bad, was fun. Now, I am looking down the barrel at two new independent projects, one iOS and one OS X.

Objective-C was never a language I felt fully comfortable with. I was competent and was able to build several projects, but I never loved it. I enjoyed the power and flexibility of the Cocoa frameworks, I loved making apps for the iPhone and iPad, but Objective-C never completely fit me well. It was a means to an end.

Swift is a different story. While there are still wrinkles in the language and the community is working through best practices and conventions, it is surprisingly capable for a new language. Apple made a smart move in using the Objective-C runtime and working to make sure it was interoperable with Cocoa frameworks written in Objective-C. This is certainly where the power and flexibility come from. But the language itself is comfortable. It takes many of the things I like from other languages and melds them into a tool that really works for Cocoa.

For my next two projects I will almost certainly write them in Swift, unless I run into a technical limitation, because it’s simply more fun. I am considering Objective-C for one of them, solely to make sure I stay sharp with the language, but I’d be surprised if I do.

It may be reckless to adopt a new language so readily, and I may regret it, but I don’t think so. I cannot imagine Apple pulling back on Swift support after the start its had. For the time being I will be plunging into the near future with Swift. We’ll see how it goes.