Skip to main content

Pretty Good Hat

What I Want From WWDC; And, Entirely Uninformed Speculation About Beats

I want AppleTV to get better in the following way: multiple cross-provider playlists of favorites, things to watch, and other things I have bookmarked. This would eliminate a lot of the need for a big UI overhaul and increase TV watching quality of life a ton.

Pipe dream: an open channel service similar to Roku that would let me plug in stuff like Rdio and, dare I say, Amazon. This will never happen, of course.

Also a pipe dream: a more visually-complete iOS app that would let me truly navigate the AppleTV menus from my phone. Use case: queuing up the next episode of Rescue Bots from the kitchen without having to get into line of sight of the TV. Come on, this can’t be impossible, right?

All I really want1 for iOS is a way to select items from clipboard history. Use case: grabbing a username and a password from 1Password and then switching to a target app where I could paste them both via two operations without switching back and forth twice between the apps. Similarly for things like email and phone number from a contact, or multiple snippets from an article I want to quote. The ease and great convenience of working with the Alfred clipboard history has spoiled me.

Beats

It wouldn’t be responsible not to speculate, at this point. Here’s my Beats acquisition theory, which more or less came to me while listening to the first twenty minutes of The Prompt discussion of the value of curation on the bike at the gym. I didn’t get to finish the show, so it’s likely that my so-called original idea was discussed thoroughly after I got off the bike, but here goes:

I agree on the increasing value of curation; there’s too much music and noise to find music that I might like, and I’ve never found algorithmic you-might-like lists very useful. In my case it’s because they very rarely can tell me why I might like something.2 For this reason I’m pretty attracted to at least the concept of the Beats music service, which is promoted as much more driven by real-person music editors.

That said, making a profitable streaming service probably relies substantially on learning what consumers want to listen to, and with 1) slow uptake of iTunes Radio and 2) streaming supplanting buying, Apple was losing out on a precious resource that Spotify, Rdio and (to a lesser extent due to its newness) Beats were eating up at ferocious rates: actual listening data.3 By buying Beats, and assuming that Beats Music does gain a foothold among users, Apple gets insight into consumer preferences that was probably steadily leaking further and further out of their vision every quarter. And as we’re learning that the intent is to run it as basically a subsidiary, it maintains the brand that the Beats team have been building, one that may be a little more vibrant to some consumers than Apple. They get a big headphone business, an injection of new industrial design and software engineering expertise along with it; seems like a really strong move to me.


  1. That’s probably not all I really want, but it’s a start, and all I can think of on this sunny afternoon. ↩︎

  2. Pandora is supposed to be better at this, but I just never clicked with that service. ↩︎

  3. Worth mentioning here is last.fm, which I have to imagine has, because of its age, by far the biggest listening history database on the planet. That they’re not at the center of all of these conversations has got to be some kind of huge misstep by CBS. CBS owns last.fm; everybody knows this, right? ↩︎

Editorial 1.1 and Me

The release of Editorial 1.1 has re-started me on the path of tinkering and tuning, and so far my impression is something along the lines of man oh man. Now, you’re going “oh great, another navel-gazing tools post,” and, no, you’re not wrong. This is another navel-gazing tools post. I do recall my college creative writing professor noting that poems about writing poems often make the worst poems; fortunately that observation probably doesn’t apply to blog posts about blog tools. We will see.

The short version is that I’m excited about this tool and this is a really powerful update. To elaborate:

  • Sub-workflows replace the previous ability to save and re-use workflows as “presets,” and improve on this idea greatly. A workflow can call another workflow as part of its own process, which means that re-using the things I’ve already built is easy, and I can improve those component workflows without having to trace their changes into the other places where they’re used.
  • The UI workflow builder is cool and I’m sure I will only use a tiny bit of its power. However,
  • Together, sub-workflows and UI builder are fantastic: I can use my existing workflows and piece them together into a parent workflow complete with buttons! In about ten minutes of work I have a popup sheet with buttons for my PGH publishing options and tools, that I can invoke from the keyboard directly. This is really, really slick. I admit I did not quite grok this when I read Oli’s preview posts about it, but the simple explanation really is true: one could use this to make full-on python-powered applications, complete with GUI, that run inside Editorial. I’m really excited to see what people come up with.

Also great, Ole’s backup/restore workflow, which has made it bang-easy to keep my workflows in sync across devices: and now with the iPhone version, I can begin work on any device and seamlessly pick up on another; this had been an obstacle between my two iPads, where I only had really tuned up workflows on one or the other. Now I’m equally capable on either iPad or my phone, no friction. It’s almost spooky, how cool it is to see the workflow panel get populated with all the workflows restored from a backup. Previously, the way to do this would be via syncing each workflow manually via the workflow repository. The brilliance of a seamlessness, easy sync just cannot be overstated. I think the ease with which one can keep iOS platforms in sync is going to be a very big deal with this release. Related, Ole Moritz has also put together a snippet backup workflow that looks likely to ease some of the frustration with the new method for using TextExpander in iOS 7.

My small kit of tools that I use to publish this entire site consists primarily of: write, upload1, render static HTML with my home built tiny engine (server side), deploy preview and deploy “production.” I have had these operations automated within Editorial for quite a while now, and every facet of doing that just got even better. Moreover, the app’s improvements give me more reason to incorporate it into even more of my non-blog style writing. In short, a great app is made even better; if you’re already a user you’re going to like it, and if you haven’t tried it but like writing and tools, I think this will be right up your alley.


  1. Really, upload here refers to syncing from Dropbox over to my web host server, where the server side static HTML rendering gets done. ↩︎

[Adactio: Journal—Selfish publishing ▹](http://adactio.com/journal/6801/)

I continue to just really, really like what Jeremy Keith writes about putting stuff out on the web:

I have to admit, I really don’t care that much about the specific technologies being discussed at indie web camps: formats, protocols, bits of code …they are less important than the ideas. And the ideas are less important than the actions. As long as I’m publishing to my website, I’m pretty happy. That said, I’m very grateful that the other indie web folks are there to help me out.

[What's New in Editorial 1.1 ▹](http://olemoritz.net/whats-new-in-editorial-11.html)

I’ve been working on this for over nine months, and in a lot of ways, it feels more like a 2.0, or at least 1.5. There’s a new look for iOS 7, an iPhone version, tons of refinements everywhere, and several major new features for building even more powerful workflows.

No kidding! What a great update to an indispensable application. Most of my posting here as well as other writing I do with Editorial, and having it available on iPhone is huge. The taskpaper support also looks intriguing. Can’t wait to see the writeups by Viticci and Weatherhead.

Pre-post update naturally, Federico Viticci already has some gajillion in-depth words written about out the update. Bookmarked.

Early Summer

lightbox2 lightbox2

The days are getting longer, so long that it’s hard these days to convince my nearly-four-year old that, yes, it actually is bedtime. A recent Saturday evening date night found us out and about downtown and I made a few pictures. The Hotel Monte Vista is, of course, a totemic downtown Flagstaff photo; and this old GMC truck reminded me a bit of my grandfather’s ‘53 Chevy pickup back home.

Since last summer I have been using Koken for image hosting and presentation here at Pretty Good Hat. It’s nice: Pretty interface, Lightroom publishing service, and produces nice galleries. Unfortunately, since my host change, uploading into Koken has frequently failed and we haven’t been able to track down the cause.

I tooled around last weekend to come up with an alternative. Although I like it the built-in gallery publishing feature in Koken, I have not used it much, instead using Koken primarily just to serve up images in multiple sizes for posting here1. So I went thinking about what I could replace that with. I started with Jeremy Friedl’s run any command plugin for Lightroom. Unlike the stock Lightroom function for running a script of application after an export, Run Any Command can work both with individual files and a list of all the files in an export, which makes it great for my purposes where I don’t want to do much file management on my own: Using Run Any Command, I can limit my processing to just the selected files without needing to keep track of previous exports that might have put output files into the same directory.

With Koken, I usually publish images to a gallery and then later return to incorporate the published photos into a blog entry. This is often on my iPad, where I use an Editorial workflow to process Koken embed URLs into markdown and then kickoff the blog preview/publish functions. So when I thought about a replacement, I knew I would want some kind of capability to ease that process — but without the nice Koken library viewer I’d need something to help me identify images and filenames.


Turns out something that does just the trick is built into ImageMagick: The montage command, as written up in great & helpful detail by Pat David, can build a nice contact sheet, or, for my usage, a tiny reference gallery that I can deposit in dropbox and quickly reference. And with a bit more code, I can add that single gallery sheet — a set of thumbnails, basically — to a dirt-simple HTML page that includes the image filenames and titles for further use.

The code

In case you’re curious, here’s how it works2. This is part of a Hard Drive export preset using Run Any Command. First there’s the Command to execute. This takes the exported file (set to appropriate size for my “fullsize” lightbox view in the LR export settings) and makes a smaller image for the blog link:

cp '{FILE}' '{NAME}'-small.JPG
/usr/local/bin/mogrify -resize "300x300>" '{NAME}'-small.jpg 
echo '<li> {name}\t{Title}' >> ~/Desktop/contact_sheet_list-$(date +%y-%m-%d).txt

And then the Command to execute upon completion takes care of the tiny gallery and file handling:

/usr/local/bin/montage -label '%f' -font '/System/Library/Fonts/Helvetica.dfont' -background '#000000' -fill '#ffffff' -pointsize 10 -define jpeg:size=200x200 -geometry 200x200+2+2 -auto-orient {FILES} ~/Desktop/contact_sheet-$(date +%y-%m-%d).jpg
echo '<img src="contact_sheet-'$(date +%y-%m-%d)'.jpg"<br>' > ~/Desktop/contact_sheet-$(date +%y-%m-%d).html
cat ~/Desktop/contact_sheet_list-$(date +%y-%m-%d).txt >> ~/Desktop/contact_sheet-$(date +%y-%m-%d).html
rm ~/Desktop/contact_sheet_list-$(date +%y-%m-%d).txt
rsync -e "ssh -i mysshkey" /Users/alan/Pictures/Exported\ Photos/tgal/*.jpg me@server:path/
rsync -e "ssh -i mysshkey" ~/Desktop/contact_sheet-*.html me@server:path/
rsync -e "ssh -i mysshkey" ~/Desktop/contact_sheet-*.jpg me@server:path/
cp ~/Desktop/contact_sheet-$(date +%y-%m-%d).{jpg,html} ~/Dropbox/tgal
rm ~/Desktop/contact_sheet-$(date +%y-%m-%d).{jpg,html}

Again, all of the montage work is cribbed from Pat David; do check out his great site. The rest is my remarkably inelegant handling of the resulting files and concatenation of filenames into a list from which I can copy filename and title/caption into a post. On the writing side, I have a textmate snippet and an editorial workflow to grab that title+caption string from the clipboard and paste their respective parts into a kramdown-flavored image link:

[![lightbox2](https://prettygoodhat.com/PATH/image-small.jpg)](https://prettygoodhat.com/PATH/image.jpg){:id: .lightview data-lightview-group="GROUP" data-lightview-group-options="controls: 'thumbnails', viewport: false" data-lightview-caption="title" }

It’s ugly, I know. But send that through kramdown and it gets the right Lightview styling and everything. So it’s actually pretty hot. I’m grateful to Pat David and to Jeremy Friedl for documenting and building, respectively, some of the tools that help me do this. Jeremy is a long-time Lightroom plugin developer and I’ve happily supported his plugins in the past — now that I’m enjoying photography more again, it’s time to re-up!


  1. I use Lightview for a lightbox-style presentation. ↩︎

  2. This explanation is really so I remember how I did this in the future. ↩︎

On Free Speech

I love XKCD as much as every other right-thinking guy who likes science and math and the internets, and this strip about free speech says something that I think is important: Namely, it’s inappropriate to frame all restrictions of expression as infringement on the right to free speech.

However, in a series of tweets, mcc makes a critically important point, that the narrow implication of the XKCD strip is that only government can act to restrict the right to free expression, which is clearly not true:

We live in a world with many systems of control. The government is one system of control. It isn't fundamentally different from the others. — mcc (@mcclure111) April 18, 2014

We — and XKCD — may sneer at CEOs and TV stars who defend themselves from criticism by invoking “free speech:” It’s hard to sympathize with the rich and powerful who stand on a national stage and complain that they have no ability to speak their minds. While the Bill of Rights expressly protects all from restrictions imposed by the government, access to free expression is not at all universal, and, like so many things, is a function of power and resources.

Tracking quality of life with Reporter

This write up by Buster Benson at Medium is a great, thoughtful piece on how he’s getting real return from the quality of life tracking he is doing with Reporter. He’s categorizing responses to Reporter surveys by whether what he’s doing at the time is “quality time” and then adding detail that at explains why or why not. It’s exactly the kind of thing I thought about recently, but much more fully realized than my current use of Reporter — and it motivates me to refine and improve my own use, to ask questions of the information I am collecting and then find ways to act on it.

The Gig Economy

Pixel And Dimed: On (Not) Getting By In The Gig Economy: Sarah Kessler really takes the wind out of the “monetize your passion in your free time” marketing of errand and odd-job marketplaces like TaskRabbit:

I spend the biggest chunk of my time, about two hours, labeling photo slideshows at a nickel each. Each of them has five photos, and each photo has 11 pages of labels to use on it. That means that it takes at least 55 clicks to earn $0.05. There are slideshows of cats on couches. Cats on beds. Dogs on beds. Cats in sinks. Dogs with cakes. Cats with cakes. Cats with pizza. Cats with windows. Dogs in car mirrors. Dogs with bananas.

No surprise, it takes an awful lot of small gigs to even begin to get by (she has one or two good days in four weeks of hustling), but Kessler’s story shows just how seriously atypical the social media success stories are.