I’m a long-time Pinboard fan, and from the moment I became a paid user I couldn’t shake the feeling that it is one of the most underrated services out there. It’s basically the center of my personal internet. I have years of articles tagged and cached, and available immediately whenever I need to remember something. For me, it represents the best of what technology has to offer as an “external brain”¹.

But it’s even more powerful than that. I recently started wondering if Pinboard could become more central in my blogging workflow as well. My flow when I find an article I want to write about used to be two steps: (1) save to Pinboard, and then (2) start a new text file (with an excerpt from the article) and start writing.

Since I don’t always have time to write immediately after I read something, the disjointedness of these two steps means that I forget to post articles sometimes — or that I can’t remember which part I want to write about. So I needed a way to save Pinboard links for later, in a way that lets me pick up writing whenever I have time.

The solution I came up with isn’t rocket science, but it has made such a big difference to the way I write that I wanted to share it here. The key is a simple IFTTT recipe that takes any new link I save to Pinboard and creates a Markdown-formatted text file that I can use to start writing whenever I want to.

Here is a link to the IFTTT recipe: Post any new Pinboard link to a new text file in Dropbox.

And this is what it does:

I always put a pull quote in the “Description” field when I save a Pinboard link, so the recipe creates a text note with a Markdown-formatted URL, the pull quote, and space for me to add a title, slug, and excerpt once I’m ready to post to the site. Putting the note in a Dropbox folder means I can continue typing and editing on any device — I use Editorial on iOS and nvALT on Mac.

As for posting… I still haven’t found a mobile blogging platform that works for me, so even though I write many posts on my iPhone or iPad, I still post exclusively from MarsEdit. So I also went one step further and made a Keyboard Maestro macro (download here) that transfers the text from nvALT to MarsEdit as soon as I’m ready to post.

You know, the internet is pretty cool sometimes.

Interesting thoughts from Steven Levy in What the Apple Watch Means for The Age of Notifications:

Done right, notifications are a wonderful Feed of Feeds, weeding out the stuff you really need to see from all the usual chaff in the stream.

But it’s hard to do this right when every single app wants to send you notifications. Even given that the system will limit itself to notices worthy of instant notice there are just too many notifications elbowing their way into what should be a narrow passage labeled, “Stuff I absolutely need to see.”

This decreases the value of all notifications.

Gmail has tried, but no one has really figured out the algorithms required to figure out what qualifies as “Stuff I absolutely need to see.” This is the holy grail of notifications at the moment.

Jason Kottke wrote what I guess can be described as a review of Apple Watch reviews. He makes a particularly interesting point about the common assertion that we’ll start using our phones less because of the watch. From Apple Watch and the induced demand of communication:

In the entire history of the world, if you make it easier for people to do something compelling, people don’t do that thing less: they’ll do it more. If you give people more food, they eat it. If you make it easier to get credit, people will use it. If you add another two lanes to a traffic-clogged highway, you get a larger traffic-clogged highway. And if you put a device on their wrist that makes it easier to communicate with friends, guess what? They’re going to use the shit out of it, potentially way more than they ever used their phones.

He also quotes from the same article I had a visceral reaction to in The Apple Watch won’t save you time. In that article I made a similar point:

I’m not saying the Apple Watch won’t be wildly successful, or that I don’t want one — I definitely want one. I just don’t think we should fool ourselves into thinking it will somehow give us more time because we might look at our phones less. If history teaches us anything, it’s that we’ll find a way for the watch to fill up our “saved” time in other ways — and then some.

My daughters love the Toca Boca apps—especially Robot Lab. Ingrid Simone’s article on their approach to gender is great. From Gender in Play: How Toca Boca Creates Apps for All Kids:

Toys have a large impact on how kids play together and relate to other kids. But kids of today are fostered into watching different shows and playing with different toys according to their gender.

We know that when a toy reaches a child a choice has already been made for them, someone has picked a blue or pink toy, an action figure or a doll. We believe this is limiting to kids, not to be able to decide on your own what your interests are, and that gender-targeted toys create an unnecessary barrier between girls and boys. And we believe that girls and boys, brothers and sisters want to play together!

And on the redesign of Robot Lab specifically:

Since the robot theme has historically been so targeted towards boys, we felt like we, as many before us, had somehow fallen in the trap of using conventional “boyish” colors, shapes and attributes. And we really wanted to see if we could make the app more appealing to both boys and girls.

Alina Senderzon defends realignment strategies in Resist the Redesign:

Yet, designers are quick to jump on redesign opportunities—after all, it’s exciting to start anew. In reality, however, a redesign isn’t always the right solution to the problem. The roadblock for users may lie in the pricing of your product, which could be discovered through customer development. Or your messaging isn’t compelling and could be saved by some clever copywriting. Or maybe customers feel compelled to convert, but the checkout process is too long and needs to be streamlined. Any number of changes could generate dramatic value for the business, and though they likely involve some design decisions, they rarely require a clean slate.

This is similar to the approach I wrote about a couple years ago in The Data-Pixel Approach To Improving User Experience.

If I link to a listicle, it has to be good enough to overcome my unnaturally strong negative feelings about those types of article. Alas, Mike Fishbein’s 4 steps to make experimentation a repeatable process in your business is that good. It’s a great overview of the importance of hypothesis testing over “requirements gathering” in product management:

Most new products fail, and most frequently because they do not meet user needs. Running experiments helps product managers validate customer demand for a product concept earlier in the product lifecycle.

By running experiments instead of launching a minimum viable product, product managers in large organizations can gain more autonomy, limit risk and brand exposure, and gain user insights even earlier in the product lifecycle. With this speed to user insight, product managers become better informed to build successful products.

I also especially liked this bit:

In the next evolution of product management, the product leader’s role shifts from making bold assumptions to fostering a culture that encourages learning in an efficient and effective way.

Scott Sehlhorst wrote a really good defense of good product roadmaps in Features do not a Product Roadmap Make:

If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” […]

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

And this, in the context of agile, is a great point as well:

A backlog – a prioritized list of features – is not a roadmap. It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.”

This reminds me of an article I wrote in 2011 called Product roadmaps are safe. Good times.

Marty Cagan has some really insightful thoughts (as usual) on autonomous teams in Autonomy vs. Mission:

In healthy teams and organizations, the way we normally reconcile these views [where the team might have one perspective and the leadership might very well have another] is that the leadership has control of two major inputs to the decision process. The first is the overall product vision, and the second are the specific business objectives assigned to each team.

Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don’t, there’s a vacuum and that leads to real ambiguity over what a team can decide and what they can’t.

The section on how to ensure consistency in design across different teams is also really good:

In the name of empowerment and also speed, my personal preference is to invest in the necessary automation (with pattern libraries and style guides) so that the team can get the design (interaction and visual) mostly right pretty easily, and acknowledge that on occasion, you will incur some “design debt” where we realize that the design needs to be corrected, and that’s fixed as soon as the problem is spotted. I like this approach because the manager of design is still responsible for developing a strong set of designers, but doesn’t have to be in the review cycle for everything (which tends to slow things way down, as well as undermine autonomy).