I like writing dashes—both the en dash (–) and the em dash (—). But I don’t like the way OS X “smartly” converts certain patterns like -- to –. I would rather have direct control over these patterns for at least two reasons:

1. If I’m writing something that will ultimately end up in a LaTeX document, I need to preserve -- and --- strings because LaTeX is designed to turn those into – and —, respectively, in the resulting PDF. LaTeX will usually choke on actual en and em dashes in the .tex file. People unfamiliar with LaTeX would probably see this as a limitation, but I truly believe it’s a great feature because it ensures that all hyphens and dashes are composed of - as a base character, making it very apparent what I’ve typed in plain text.
2. Even if I’m writing something that won’t end up in a LaTeX file, I can easily create en and em dashes manually by preceding the - key with Opt for an en dash and Shift-Opt for an em dash. Both work system-wide in OS X.

In other words, I don’t need OS X to be “smart” enough to make these symbols. I can instantly create them myself according to how they’ll be used.

Before OS X Mavericks, you could explicitly turn off smart dashes in System Preferences. Beginning with Mavericks, however, dashes and quotes were forced to share a common check box.

I don’t really mind curly quotes showing up in places because even if I’m writing something for a LaTeX file outside of a .tex environment (e.g. in an app like Ulysses), I will normally run everything through Pandoc to generate proper LaTeX code. Pandoc is pretty good with translating quotation marks of all kinds into proper LaTeX syntax:

``quoted text''

It’s not so good, incidentally, with en dashes, which are more ambiguous in meaning—some people use them in place of a subtraction symbol, while others use them in contexts where em dashes are more appropriate.

All that to say, it’s unfortunate that you can’t separately turn on/off smart dashes and quotes in System Preferences. Fortunately, though, you still can through Terminal with:

defaults write 'Apple Global Domain' NSAutomaticDashSubstitutionEnabled 0

This command turns off smart dashes, allowing you to preserve --, etc. in any document, but it allows smart quotes to continue functioning. Interestingly, System Preferences will show the smart dashes and smart quotes box unchecked after this change even though smart quotes still work.

For more on dash usage, see The Punctuation Guide.

Being somewhat old fashioned, I sit at my desk a lot instead of standing at it. I also have carpet in my office, so I usually don’t wear shoes. The First World problem that this creates is that I tend to put my feet in what are apparently ergonomically disastrous positions without thinking about it.

Experience has shown me that putting unnatural pressure on my feet for extended periods of the day—while not painful at all when I’m doing it—tends to cause my feet to scream at me the next day. As I’ve gotten older, the screaming has gotten louder and lasts longer.

My solution: I bought a foot hammock, which I highly recommend.

AgileBits is leaving Slack:

Slowly but surely this addiction has been killing my sanity and sapping our productivity as we simply used Slack for too many things. We decided it was time to try a new approach for communication at AgileBits.

Honestly I agree with everything here. I like Slack, too. A lot of people seem to like Slack. But my experience with Slack is that it’s a Markdown-supported chat client on steroids. Right now I’m only using Slack to keep in touch with a couple of friends on work breaks. I can’t imagine working with Slack open all day. I definitely can’t imagine scaling it up for more than a two- or three-person team and not spending time talking all day.

I feel totally different about Basecamp, especially the new Basecamp 3. To me, it feels like more of a virtual office space, and it’s partitioned into a more logically-productive way. I think AgileBits is going to like Basecamp 3 a lot. I can’t recommend it enough for working with a small-ish remote team.

Now that the smoke is clearing and Smile’s dastardly attempt to charge more for its product has been “adjusted,” we can talk about more important aspects of this transition. Specifically, Gabe describes Smile’s decision to not encrypt TextExpander snippet data as:

A design choice like that has consequences that I’m not comfortable with. It’s not something I want to use or recommend.

The word “recommend” zeroes in on the fundamental thing I’m struggling with as more developers abandon Dropbox and iCloud in favor of their own syncing platforms. It’s not really about the cost of the services to me. That’s something that I feel I can objectively evaluate myself.

The more difficult decision process now is:

1. Am I OK using it? And if yes,
2. Would I recommend it to someone else?

Before data privacy became such a thing, Decision No. 2 was almost always naturally a yes if Decision No. 1 was a yes. It’s not so simple now.

An even better case study than TextExpander is YNAB, which shifted from a pay-per-upgrade / desktop app / Dropbox sync model to a subscription / web app model earlier this year. While I’m using the new YNAB and still feel that it is lightyears ahead of any other personal finance software because of its budgeting philosophies, actually recommending the new version is a far more complex decision than it was when user data wasn’t stored on YNAB-controlled servers and bank data didn’t sync “through the cloud.”

Now, the recommendation decision is a function not only of the benefits of the software but also the risk management implications on the data side. The reason that I am ultimately comfortable with the tradeoff has less to do with my perceived security around the YNAB servers and more to do with:

1. How selective I am with which bank accounts I sync
2. Other backstops I have in place at the bank level (transaction alerts, fraud alerts, how I distribute savings across different accounts, and even my decision to keep my credit frozen)

I can’t expect that other people will have the same things in place, but those things are now inextricably linked to my personal experience of the software—making my experience far more singular, nuanced, and much less “lift and move” to someone else’s life.

So. Software is getting better. Software is maybe getting more sustainable through subscription pricing models. But the psychological benefits and costs of using software have never been more complex. As I’ve said before, software is fundamentally a knowledge resource—an abstract layer on top of the physical universe created by humans for humans to grapple with. Software is truly as human as it gets—a medium through which problems are solved and as many new ones are born.

And software and data are now more inseparable than ever. This was inevitable: They are made of the same stuff. Software is a developer’s knowledge; my data are my knowledge. Where should they be allowed to play together? The developer’s house? My house? Or some sandbox in the sky?

I can answer these questions for myself. But for someone else?

In case you haven’t heard, the Apple Watch has now been declared a failure because of at least two categories of shortcomings:

1. It has failed humanity: It has not cured cancer, curbed the incidence of global terrorism, and it has neither confirmed or denied the Big Bang theory
2. It has failed developers: No one can program around the same splash screen: a 60-second spinner

Maybe I’m a Watch apologist, but the Watch’s failures have not made me wear the Watch any less or feel that the roughly $400 I spent on the Watch was wasted.

Considering the frequency with which I’ve used the Watch every day for nearly a year now, the graph of my investment in the Watch per unit of utility is an asymptote teasing zero. For me, all of the following have been enough in Watch version 1.

• The time on my wrist. I foolishly let the iPhone replace previous wrist watches. The Watch fixed that.
• Weather. The Apple weather complication is always current, forecasts load quickly, and I find the clockface-like weather forecast superior to virtually every iPhone and desktop weather app UI.
• Next meeting complication. It’s useful.
• Activity. I move more when I know how much I haven’t been moving.
• Notifications. I’d rather see most of them on my wrist than have to fish a an ever-growing iPhone device out of my pocket.
• Hands-free calling. This was the most unexpected benefit, but the Watch is my preferred way to take calls in private, especially in the car.
• Easy Siri questions. “What time is the sportsball game tonight?” or “when is Easter this year?”

I’ve all but abandoned using third-party apps on the Watch, but the breaking of that promise hasn’t made me want to discard everything that does work.

I don’t know why I wrote this post, but after seeing all the vitriol spewed at Smile for changing their business model, I started having these crazy thoughts in my head. This is all stupid, but for what it’s worth…

What if the typical developer isn’t a rich Wall Streeter making a money grab? What if developers are girlfriends, boyfriends, or partners? Maybe moms and dads? Maybe developers have mortgages, rents, car payments, and health insurance.

Maybe they’re wondering if they will ever have a dollar to spend on themselves after they scrape up enough to save for their kids’ college—or take care of an aging parent.

I guess what I’m saying is, what if developers are just human beings. Normal people?

And what if they’ve been failing? What if they keep getting up at one o’clock in the morning to open their laptop to take one more look at a spreadsheet, desperately hoping they’ve made a mistake. Maybe there’s a formula error somewhere. Maybe, just maybe the sales are there after all. Maybe they won’t have to take another contract job. Maybe they won’t have to let an employee go—another normal person with a mortgage, a kid, or a family to take care of.

Maybe they’re sick to their stomach thinking of what has happened to developers before them that “fixed” the same problem by

• Letting the app die
• Letting the app languish
• Putting ads in their app
• Selling their customers’ information to marketers
• Selling the whole business to a giant tech company

Maybe they’re dreading the one-star shame that they know will come with any of those decisions.

So what if they decide to do the unthinkable. They raise the cost of their product to stay alive another year. To fight the good fight one more season. To keep their homes, their kids’ college fund, their family’s health. To secure their dignity—the very essence of their identity as an independent human being.

What if developers raise prices not out of greed and malice but out of necessity? And what if they don’t deserve to be spit on for asking to be paid? Like us?

Told you it was crazy. Forget I said anything.

Like so many other apps-turned-services in the last year, Smile is moving TextExpander to a subscription model that will cost $4.95 per month (or something less if paid annually).

Macstories:

Pricing is hard to judge because everyone values software differently. By the same token, TextExpander is not a new app – it has been around for many years as a paid-up-front utility, which is what this new pricing model will be measured against by existing customers. I can’t help but feel that those customers will be unhappy, perhaps very unhappy.

I’ve been quietly observing the shift from “pay once” to “pay ongoing” in the world of software but haven’t said much about it. There is, however, so much to say, and I think for me it fits messily into two overlapping psychological circles, which I discuss below.

We use software, but we haven’t figured out what the hell it is

People usually talk about “software as a product versus software as a service.” The conversation, however, should be about “software as a perception.”

What is software?

I can’t touch software (only hardware). I can’t smell software. I can’t taste software.

But I can look at software. I can use software. I know software when I see it. I can sense the benefits and experience of using software. I know that software exists—at least in my mind.

Even though anyone can plainly understand that software isn’t a durable good or a product in the physical sense, that’s how it was priced in its first era in consumer markets. Like cereal, we used to buy software in boxes off the shelves of physical stores. Such silliness was never going to last, nor will the silliness of paying once to download a .dmg file.

The reality is that software is knowledge: words and bits and instructions conceived by humans and experienced by humans. Software obviously requires a hardware infrastructure (both locally and networked) to exist, but software is fundamentally an abstract knowledge layer on top of a physical infrastructure. We need both the hardware and the knowledge layer to get the full benefits of software, but understanding the difference in these two layers is crucial, I think.

Is knowledge a service? Most of the time—probably. But certainly not always.

If we think of software as a knowledge service, then charging an ongoing fee seems to be a market consistent approach. In other words, it boils software down to its elements (knowledge), and we can observe how knowledge is priced and bought in other areas of the economy. For example, consultant fees, retainers, etc. No one would expect to pay a lawyer a one-time fee for unlimited support until the lawyer died or became replaced by a newer, faster lawyer with a flatter and less skeuomorphic face.

But that’s what we expect of software developers, right? Pay them the cost of a counter service meal once for the right to email them and require support indefinitely? At best, this kind of business model scales to masochism. At worst, it drives software into either abandonment or acquisition by tech giants that shit it out in unrecognizable pieces and privacy violations.

Software is infinite. Disposable income is not.

Back in January, I randomly tweeted:

$5/month is a reasonable charge for your service. Problem: your customers also need 100 other non-competitive subscription services.

I think this resonated with a lot of people who hopefully got what I was trying to say, which is that the software economy is out of sync with consumers’ disposable income. This is not the fault of developers or people who buy software. We’re just living in a REALLY different world than I think humanity has ever experienced, and we won’t even fully understand how fundamentally different the world is today than it was even twenty years ago for probably another hundred years. In other words, we’ll probably never get it. We’re just living it.

Fact: I can’t work without apps like TextExpander, and from a purely rational economic perspective, there’s no reason not to pay Smile $50 a year. It hurts me more not to continue using TextExpander.

There are many other pieces of software for which I feel the same. And there will undoubtedly be many more in the future. This highly heterogenous set of services will not compete with each other so much in quality as they will compete for access to a homogenous resource of dollars—my finite income.

How will we align consumer incomes with the Age of Services? Can we really afford all the services we want with income alone?

Of course not.

Maybe future software markets will paradoxically revert to more traditional economic structures where we trade services for services instead of income for services. Maybe coding will become as fundamental a skill as building your own home was a few hundred years ago so that we can build our own services more easily. Maybe future generations will shift more disposable income away from materialistic goods to services. Who knows—I don’t write the future.

For now, we’re living in transition, and we’re arguably just now repaying a knowledge debt we’ve been accruing. We’ve been living on borrowed knowledge. The bubble is bursting. It’s time to either pay or default and live with the consequences.

My time with Squarespace ended today. It was never an entirely happy marriage between us, and it’s not worth spilling every detail why, but I will say that the main thing that ultimately drove me from Squarespace for good was its poorly implemented Markdown editor.

I feel that I should qualify that “poorly” because I really do mean poorly for me, and I don’t have any fantasies that I’m a typical Squarespace user or that I know more about Squarespace’s user base than Squarespace knows. I fully believe Squarespace has designed its user interface with its primary customers in mind.

But as it stands now, Squarespace is not a place for lovers of Markdown, and that is who I’ve been for years and likely always will be. Even though Squarespace was among the first major blogging platforms to welcome Markdown-based blogging, I don’t think the Markdown functionality in Squarespace ever got past “add-on” status. It is a window within a window within other windows and will likely never be front and center in the user experience.

All of these things have been said before about Squarespace, and I can’t think of anything to add to Claus Wilke’s take on it:

While Squarespace posts can in principle be written in Markdown, Squarespace’s Markdown capabilities are limited and buggy. In particular:

• Code blocks are buggy. Specifically, Squarespace doesn’t properly escape special characters in code blocks. This can make embedding code into Markdown posts a big headache.

• Images cannot be inserted directly from the Markdown.

• To insert images, one has to break the Markdown into two parts and insert an image block in between. As one does so, Squarespace rewrites the Markdown and turns all inline links into reference-style links. While this doesn’t alter the page output in any way, I prefer to use software that doesn’t randomly rewrite my source code.

• The online Markdown editor Squarespace provides is slow and buggy. For longer pieces of text, the cursor is often displayed at the wrong location, so that it becomes difficult to edit the text at all.

Life and content go on… to Jekyll

It’s fitting to quote Claus above because he was writing about why he moved from Squarespace to Jekyll—footsteps that I’ve now followed.

As blog nerds and GitHub power users know, Jekyll is a popular static blogging platform that lets you write and maintain all post content in Markdown. Like other static frameworks, Jekyll basically builds a database-free, static HTML website from Markdown and other configuration files. Though the setup takes some nerdery, the final result is as basic and pure a thing as you can find on the internet: a folder structure of HTML files.

Jekyll is not the first static platform I’ve attempted to move to, and I’m grateful my previous attempts to move to other static frameworks failed because I can’t think of a better place to be than Jekyll now—although many, many good static site options now exist.

Ultimately I chose Jekyll over other options because:

• Jekyll is very popular and well developed.
• GitHub—the center of the developer universe—loves Jekyll and uses Jekyll to power virtually all of its user-editable pages.
• Since GitHub is so Jekyll-friendly, I was able to host the whole site there for free. At some point I may move to my own server, but it’s super convenient to have a powerhouse like GitHub take care of running Jekyll to re-build the site when something changes, not to mention the obvious local syncing benefits with any GitHub repository.
• Jekyll’s framework for Markdown files with YAML front matter is substantially the same as other popular static platforms making it easy to switch to something else down the road if necessary.

A static site is very close to the antithesis of Squarespace in terms of user skill set required. Many people will rightly question the value I’m gaining by simply being able to write and maintain my site directly in Markdown. If that were the only criterion, I think fair arguments could be made against my moving.

But for me, the value of the move is much longer-term in nature.

• I got to sharpen my Shell and Python scripting skills while cleaning up my old posts to make them Jekyll-ready.
• Converting all of my older posts into Markdown files means I now truly own the things I’ve written and can easily move them anywhere. They’re out of the black box.
• I learned a little Ruby, which is what Jekyll runs on.
• I learned much more about GitHub than I used to know and plan to put that knowledge to work for other projects.
• I learned more CSS tricks and discovered the power of SASS, which actually makes me not hate working with CSS anymore. So useful.
• I’m in the process of learning some cool tricks in iOS that I plan to use for iOS-based publishing.
• I no longer rely on first-party apps for publishing.

Overview of how I moved

There’s no such thing as a boilerplate list of steps for moving from Thing A to Thing B on the internet. To each his own sub-steps. And it’s in those sub-steps where both dragons and fun be alike. But for those that care, here are the primary steps I took over the course of several nights and weekends:

1. I exported my Squarespace site to a WordPress XML file (the only option).
2. I used this godsend of a Ruby script by Evan Walsh to convert the XML file into individual Markdown files. This was a major leap forward, but in reality this is where the real the fun began.
3. I wrote several Python scripts to clean up the Markdown file names and insert YAML fields for things like redirects. This was a major step, and I think I’m going to put these in a different post because they were fun to make and worth saying more about on their own.
4. I installed Jekyll on my Mac so I could build the site locally on my Mac and experiment with things. I highly recommend this even though GitHub can build it for you too.
5. I spent a lot of time reading the Jekyll documentation and learning how to work with the Jekyll framework, which can seem intimidating at first if you’re not a web developer, but it quickly collapses into a beautifully intuitive framework. It’s so worth the time to learn if you want to empower yourself with a static site.
6. I spent a few nights tweaking the CSS of the stock Jekyll theme to make it look like I think Practically Efficient should look.
7. I moved the files to my GitHub account, flipped a few DNS switches, and was done.

Other good resources:

• “Build a Blog With Jekyll and GitHub Pages”
• “How I Created a Beautiful and Minimal Blog Using Jekyll, Github Pages, and poole”

You may be wondering about images. Fortunately I have local copies of nearly every image I’ve ever posted, so I didn’t need to pull those off Squarespace.

Some thank you’s framed in bigger pictures

Even though I didn’t solicit much direct help in this move, I’m so grateful for the inspiration I’ve gotten from Gabe Weatherhead, Ryan Irelan, and Dr. Drang. They’re all much handier than I am with static blogging and web things in general, but I’ve been influenced heavily by what they’ve done. In particular, I’m convinced I would not have the basic Python skills I have now if it weren’t for all the exposure I’ve gotten to it through Dr. Drang’s posts.

Thank you all for being you.

Even though indie blogging has been relegated to third-, fourth-, maybe fifth-class citizen status on the internet in the last few years, I’m still grateful it lives on through the people who won’t let it go. I’ve seen so many talented, passionate bloggers move on to other mediums like podcasting or get sucked into aggregator-ish, socially-charged platforms like Facebook and Medium to chase the high of extra-instant attention, only to find that individual thoughts quickly wash away in a relentless social tsunami that leaves no trace of individual identity or permanence.

If static sites increase the longevity of indie web writing, that’s just one more reason to support static blogging and the individuals that freely share information that empowers others.

Practically Efficient’s RSS feed has changed to:

http://www.practicallyefficient.com/feed.xml

Please update your favorite RSS reader if you’d like to stay subscribed.

Clickable RSS link

In case you didn’t hear, OmniFocus 2.5 finally brings back custom styling. Overall, I’ve been happy with the general OmniFocus 2 UI design choices. Except for one major fault: the default task note text color is miserably hard to read. I spent about five minutes fixing this with the OmniFocusColors app, and I’m not looking back.

For me, task notes are super important—as important if not more than the task itself. I want to notice them and use them.

In 2016, people are still judging the iPad’s viability in terms of what you “can also do” on the iPad.

And they’re right. Because the day the iPad can do everything the Mac can do, we, as a civilization, can finally move forward. For at that point, we will finally have a computer that does everything the computer we already owned was capable of doing.

For most knowledge work, completion is the wrong goal. It’s an illusion. Simply being better is the right metric.

Better in technique. Better at knowing the truth. Better at knowing what not to do. And every day, better than the day before.

I have become a huge fan of Pandoc for converting Markdown to LaTeX code. It’s especially useful for outline-heavy text because it lets me avoid the more cumbersome itemize and enumerate environments in LaTeX during the writing process.

My Markdown to LaTeX workflow has gone through several refinements and is now as efficient as ever. I simply write a block of text in Markdown, copy it, and run a Terminal command:

pbpaste | pandoc -f markdown -t latex | sed -e 's/\\tightlist//'  | pbcopy

This command sends my clipboard contents to pandoc, which converts the Markdown to LaTeX. It then pipes the pandoc result to a sed command, which removes the \tightlist command from the LaTeX code produced by pandoc since I have no use for it in my final code. The final result ends up back on my clipboard via the final pbcopy command so that I can just paste it anywhere—often right on top of the Markdown I originally copied.

I usually run short Terminal commands like this by turning them into plain text TextExpander snippets and running them through Alfred preceded by >. There are arguably better ways of doing this.

Alfred makes it very easy to create a file filter that looks at one or more folders (not necessarily near each other) with specific extensions (e.g. PDF) and other attributes. I have several of these very simple Alfred workflows that I use all the time to locate reference PDFs and also PDFs that I’ve created.

It is by far the most efficient way I’ve found to pull up a file if I know it’s general nature and just a piece of the file name. Spotlight is great, but it’s too big a net in many cases. With Alfred, I can type a short keyword, a piece of the filename, and it’s instantly in view without even leaving site of other windows I have open.

The only friction with these workflows happened when I was searching folders containing PDFs that I periodically duplicate and update by putting a new version number on the file name. For example, a folder could end up containing ABC-v1.PDF through ABC-v10.PDF. In most cases I want to go straight to v10.

Fortunately I’ve long used the stock OS X file colors (which are now technically tags) to highlight the “active” version. I had always done this as a visual guide so that if I entered the folder with Finder, my eye would go straight to the important copy.

Very recently I discovered that Alfred file filters can also filter on tags. By adding the kMDItemUserTags metadata field and setting the value to Blue, which is the color I use to denote active files, it restricts the Alfred workflow results to only Blue-tagged files. This cuts the results returned by Alfred even more so that in most cases I see only one or two PDFs after typing even the tiniest bit of the file name. It’s so great.

I’ve always had a special place in my heart for application launchers, but Alfred has become this essential layer on top of OS X that makes the basic Mac file system a remarkably efficient content management system.

Kevin Spacey:

It’s very easy to live your life the way you want to. It’s the way I’ve always been.