Went and got an iPhone

For a while there back in 2010 I kept waiting on the promises (by which I mean rumors) that the iPhone would soon-anyday-now-for-real be coming to Verizon. (whose signal is quite a bit better than the alternatives in my mountain town, and I get a company discount, too) But the time came I was tired of waiting, so I eventually pulled the trigger and went for a Droid X. And I liked it, and it worked very well for a while, and I spent quit a bit of time tuning applications and integrating it into my Mac desktop and workflow.

But along the way it started to get unstable. It wasn’t uncommon for it to hard-freeze while in the car dock, or if I locked it while using the camera app. It seemed to slow down, too, taking increasing (and increasingly frustrating) long times to do things that a phone should just do, like make calls.

Also, I dropped it three months ago and the rightmost fifth of the screen went dark. Do you know how much stuff, important stuff, is over there? The clock, scroll bars, send and submit buttons in a whole lot of apps, for example. Oh, the comedy of my rotating the phone to reveal a button, or blindly tapping in hopes of finding “send.”

So it was a good run, little, er big honkin’ Droid, but when my clock came up and I could upgrade, I was at the VZW store when it opened (this part was actually by accident, but I was the second guy in the door that morning) and came home with a black 32gb 4S.

Oh. My. There’s just. Why didn’t anybody tell me? It’s so good, and all the slavering over specifications at the gadget blogs about multi-core and 4.6-inch droid screens is just utter nonsense all of a sudden, because Apple just nails this thing.

I turn on the camera app, and there’s the camera. Not only does the app simply start up with a barely perceptible delay, but the quality absolutely smokes that of the droid. The camera lag matters more as my toddler gets faster; waiting for the camera to boot was okay when he was immobile, but the guy is on the move now, people, and shutter lag and slow startup were getting in my way.

The screen is gorgeous. Crisp, clear, colorful. Apps that I got used to working with on the droid — like 1password, tweetdeck, instapaper — are instead shockingly usable.

Tapping a phone number makes a call. I don’t wait, wondering if the tap registered. FaceTime is a revelation, one which my toddler is just agog over.

I mentioned my switch on the twittermatic, and a contact of mine expressed surprise to see me make the move, indicating that he expects many more to move in the opposite direction. Now that I’ve switched, I cannot imagine it. To be fair, android is — probably — forcing Apple to be competitive and pay attention to the apps and features landscape, but the past two years I’ve spent with my own droid is all I need to be very confident that nobody has the full packages together nearly as well. If there’s movement toward android right now, I expect it’s from first-time smartphone shoppers corralled by in-store salespeople. (I think smarter observers than I have made this point.) And as we come up on two years since the Verizon iPhone, I predict a surge of movement from VZW droids to iPhone.

Me, I’m happy.

Clay Shirkey on SOPA

As part of this week’s SOPA blackout protest, Clay Shirkey gave a great talk that puts the issue in context. (Bonus reading: Yochai Benkler’s Wealth of Networks)

Later he wrote a response to David Pogue on SOPA. Arguing that Pogue underestimates the controlling intent of the media proponents of SOPA:

And arguments like Pogue’s are dangerous not because they are pro-SOPA — Pogue himself is glad it is in trouble — but because they obscure the core historical fact: The American media industry tries to stifle user freedom. Every time. Every single time.

We should delight in the stand we’ve taken in favor of things like, say, notifications, and trials, and proof before censoring someone, but we should get ready to do it again next year, and the year after that. The risk now is not that SOPA will pass. The risk is that we’ll think we’ve won. We haven’t; they’ll be back. Get ready to have this fight again.

WriteMonkey: a lightweight text environment for Windows

I recently came across WriteMonkey, a very good “zen” — or minimal distraction — editor for markdown. This came along at just the right time for me to draft a couple of documents in a situation where I wanted to get away from the standard office software environment: I needed a bit of a break and wanted to just work in plain text with a little markup for a while.

WriteMonkey handled the task perfectly. It can push a document, styled per a custom style sheet or using its own built in CSS, to Word or HTML for printing or sharing — quite handy.

And then I discovered how much it has under the hood, and found that it’s more than an editor, but a full-on machine for working in text files. It has what it calls “jumps”: regular expression-based search terms that, when matched, can define the maching block of text with any arbitrary designation. Then a built-in navigator pop-up shows those blocks in a list. So, one could define a regex match with TODO at the beginning of a line and use the jump viewer to display all the TODO items in a file full of stuff. (This was the first thing I did, based on the tips at the writemonkey site).

I set up a couple more, too: A regular expression to show a particular header format in a journal file where I quickly dash off notes to myself, and one that shows the first part of text snippets from drafts of language I’m working on in other documents. There isn’t support for multiple windows (comes with the full-screen “zen” option), but WriteMonkey lets you quickly ctrl-tab between recent documents.

Finally, WriteMonkey has a built-in scratch space for every document, accessible via alt-r. It’s a great place for storing all those snippets and todos that accompany the main document, without cluttering up the main text. All that and it’s a portable app: No installation or anything required other than clicking the executable. In two days of use it was a huge help at creating a nice environment for doing the writing and organizing I had to get done.

Ride the Divide - race visualization

I watched Ride the Divide on Netflix tonight. It’s a really well put-together documentary about a mountain bike race from Banff, Canada, across the entire great divide, to the New Mexico-Mexico border. It features great photography and strong characters in these semi-nuts enthusiasts who take on the adventure, and turns out to be a pretty moving story.

It also has a bang-up cool race visualization:

Ride the Divide image
Ride the Divide image

The image features the relative positions of all the racers along the route — leaders, followers, and distance between them — their current altitudes, the mileage and location of the current subject, day of the race, relative distances to travel through each state, elevation of the overall route, and total travel distance for the entire race (2711 miles!). In a single, dense image, you get a ton of data. Quite cool.

Using Alfred to manage tasks

Recent updates to Alfred (my earlier post here) have greatly enhanced its capabilities to run local scripts and extensions. I’ve long used the Journal Tasks TextMate bundle in conjunction with geektool to manage and display a small to-do list in one corner of my OS X desktop, and now with Alfred I can instantly add items to that list. Quite slick.

Here’s the task list viewed in TextMate: Simple and no frills.

quick list textmate

And geektool displays it on the desktop using a bit of awk:

awk '!/@done/' ~/DropBox/SimpleText/Quick\ List.taskpaper

quick list desktop

I’ve set up an Alfred extension to add to the list using the “do” command:

alfred quicklist

The command in Alfred looks like this:

perl -p -i -e 's/^Quick List:\n/Quick List:\n\n- {query}/' ~/Dropbox/SimpleText/Quick\ List.taskpaper; growlnotify -m "Added item to quicklist"

It finds the header for the appropriate part of the list, and inserts the query passed to it at the top of the list. (Update paths as appropriate; I keep my quick list file in my DropBox folder.)

Growl provides a nice visual confirmation that the item has been added. I still have to open the file in TextMate to mark items as @done and periodically expunge completed items, but it’s great to be able to effortlessly add to the list.

The entire Alfred extension is at github.

The Setup by the Numbers

I recently found myself browsing interviews at The Setup, where various nerdy and creative types describe the tools they use to do their work, and my curiosity sparked at this brief statement on the about page: “Despite appearances, the site is not actually sponsored by Apple – people just seem to like using their tools. We’re a fan, too.”

Wouldn’t it be interesting, I wondered, to know just how many of the interviewees were Apple users? And what they used? And, for that matter, how many were into Android, or Lightroom versus Aperture, or emacs or obscure outlining applications that absolutely nobody else uses?

The code for The Setup is on github, and it includes the text of all the posts! The interviews are in markdown format, and the processor generates links for product names by referencing an index of hardware and software. This is the key for someone like me who wants to make data, because it provides a (mostly) standardized catalog of gear, no content coding required. It also means that the interview text can be descriptive while also referring to the standardized name for that bit of equipment, as in [15" MacBook Pro][macbook-pro].

The ruby code that builds The Setup from those files even helpfully includes a ready-to-go regular expression that finds those hardware and software references. So with a few of my own inelegant but functional passes using grep, perl and awk, I built a tab-delimited data set from which we can learn all sorts of things, such as:

  • More of The Setup interviewees are into Lightroom than Aperture
  • Apple machines really are popular (and so are iOS devices)
  • Textmate still has a lot of adherents
  • Canons are more popular than Nikons (though it’s pretty close)
  • Nobody yet interviewed has a Xoom or Galaxy tablet
  • Very few iOS apps are named more than once (not even Angry Birds)

I’ve used R to put together an easy-to-update, full rundown of the numbers (see usesthis-summary.txt) that I thought were interesting and/or fun, but you can easily explore via awk, too. For example, the following finds and counts all unique iOS applications:

awk ' {FS = "\t"} { if ($4 ~ /\-ios$/) print $4 }' thesetup-data.txt | sort | uniq | wc -l

There are a few limitations to the making of grand statements about this data: Of course each interview is a static snapshot, and we have no idea (without asking) if, say, Marco Arment has moved his work to a HP touchsmart, or Kieran Healy has switched to SPSS and MS Word, or if all the reported 3G users are still using that model of the iPhone. [Idea: break down some of the numbers by year.] There are also the occasional instances in the interviews where someone says something like, “I can’t imagine using something,” and due to the context-dumb nature of this data, that becomes a count of that something in the index. The counts rely on some skimming of the hardware/software catalogs and subsequent manual coding to identify models of gear that fit into various categories (Windows PCs and Android devices that come in all makes and models, for example). These will probably need periodic updating.

The data, the code to build the dataset, and the R code to run some numbers are all available at github.

All of this is possible thanks to the cool coding behind The Setup (imagine the work required to build a catalog if the interviews were simply static, hand-built html), the careful curation of interviews to make use of the hardware and software catalog, and the Attribution-ShareAlike licensing of the original — which licensing applies to this effort, as well. Thanks to Daniel Bogan and contributors to The Setup!

(One note about the interview count: the interview with why the lucky stiff is hand-written and so doesn’t register with the scraper. But it’s good, so you should read it.)

Alfred is my favorite new launcher

Back in the day, Quicksilver was the hot app for OS X. I hadn’t used it for years, now; at some point it seemed to become unstable, and its indexing sucked up a fair amount of CPU. So until recently I’ve been launcher-less on my Macs. Oh I checked out the occasional alternative like Launchbar, but never took to it.

But now I’m using Alfred and seeing the launcher light once again.

Alfred is nicely capable on its own: Invoke it, type an application or file name, and Alfred displays the matches, each with a hotkey to activate. But with its Powerpack, it gets just fantastic, with dedicated shortcut keys to active popup finder navigation, a mini iTunes player and a Clipboard history. The keyboard shortcuts continue — each popup gives hotkeys to the options it presents.

These tools have replaced my normal modes of navigating on the MacBook. It’s so easy to invoke any of the powerpack features to find and email a file, fire up a playlist, or simply launch/switch applications. What I used to do with quicksilver, I’m now doing with Alfred, and loving it.

[The launcher app itself is free and available on the Mac App Store; the powerpack, which turns up the capability to 11, costs about $20. Worth it.]

Happy new year! Here's something cool from pinboard

Happy 2011! I’m considering some end-2010 thinking that may end up posted on ye olde blogge, but in the meantime here’s a nice treat from pinboard: A great customizable tag cloud widget (that’s a screenshot, not linked):

pinboard tag cloud screenshot

I’ve been using pinboard for about a year now, and have been nothing but happy with it. Now that the days for delicious are numbered, there’s no reason not to pay the signup fee and give it a try.

Great Android apps: Vignette

I’ve been using the Vignette app for photography on Android ever since Dawn recommended it to me. It allows me to tap to shoot (avoiding the balky Droid X camera button) and offers a bunch of shooting options.

It also offers dozens of filters for creative photo-making, any of which can be applied either at the time of taking a shot, or later, to any photo in the Droid’s gallery. In fact, there are so many filters that I have trouble keeping track of all of them, and developers neilandtheresa (who, by the way, have an utterly charming blog and web site – and also see their official site for Vignette) continue to add more with each update to the app.

So I cheated and made myself a handy reference for the current set of built-in effects. It’s a little unwieldy to use on the droid itself, but not too bad — and it’s a big help for thinking about post-processing of photos that I’ve already shot. It includes examples of the vignette, coloring, camera and film effects styles and more. I hope it’s helpful to you. Click through for the full-size sheet at flickr.

Vignette App for Android | Effects examples

Keep in mind that the effects can be layered on top of one another via the customizations menu, allowing the stacking of any number of treatments. This sheet doesn’t show any of those combinations.

One hint for working with Vignette: Set a favorite preset with all effects, frames and customizations to Normal/None; then you can quickly toggle from fancy-pants artistic to straight normal settings.

For the sake of completeness, here’s a list of all the effects currently in the application (note that not all simple color variations are included in the example sheet).

1. Normal - Generic film effect
2. Vignette
3. Portra
4. Velvia
5. Ilford
6. Toy Camera
7. Toy Camera BW
8. Leaky
9. Cross-Process
10. Faded
11. SX-70
12. Summer - hazy grns and browns
13. Colourised - flat pastels
14. Oversaturated - bright washed out reds & yellows
15. Yearbook - faded B&W
16. Sepia
17. Platinotype - bright smooth tones & deep shadows
18. Retro Red - faded color variation
19. Retro Yellow
20. Retro Green
21. Retry Cyan
22. Retro Blue
23. Retro Magenta
24. London - contrasty b&w and red
25. Paris - contrasty B&W and blue-green
26. New York - contrasty black & white and yellow
27. Red/blue
28. Red/green
29. Blue/green
30. Rotate Hue
31. Sepia - same
32. Platinotype - same
33. Bleach bypass
34. Night vision- grainy and green
35. Duotone red, yellow, green, cyan, blue, magenta
36. Dreamy - soft-focus
37. Tilt-shift - portrait and landscape modes
38. Tobacco filter - deep orange tint for dramatic skies
39. Grad tobacco - portrait and landscape
40. Grad ND - portrait and landscape
41. Red, yellow, green, cyan, blue and magenta simple filters
42. Action movie - vivid reds w/blue-green tint
43. Technicolor - red and cyan 1930s look
44. Scary movie - tri-tone blue and magenta
45. Posterise
46. Blackboard
47. Infrared
48. Rainbow
49. Negative
50. Invert
51. Bordered
52. Rounded
53. Oval
54. Instant classic
	variants: Wide, mini & square
55. Instant transfer 1
	variants: 2 (smaller border) and 3 (yellow/magenta border)
56. Filed carrier
57. 35mm
58. 35mm full bleed
59. 6x6
60. 6x6 full bleed

Sync Lightroom Galleries to Android - Automatically!

Now that I have a photogenic, tiny gurgling creature in the house, I’m shooting a lot of photos, both on the Droid X and the Pentax. Most of these photos end up, one way or another, in Lightroom for cataloguing, and as I’ve described earlier, I have a nice workflow for updating these rapidly-growing galleries on my iPad.

But how about the Droid X? It has a nice screen, and I want to foist photos of my beautiful boy on anyone I happen across — so I started to wonder if, continuing to use Lightroom as my core platform, I could keep a small gallery of photos on the Android phone with as little manual work as possible.

Here’s the executive summary: I again use a smart published collection in Lightroom to create the gallery; then I use a LaunchAgent in OS X to monitor the mount point of the Droid X on the filesystem; and a tiny shell script syncs the published gallery to the Droid whenever I plug it into the MacBook Pro. Read on for altogether too many details.

First, a couple of things to note about how the Droid X generates image galleries [ note that this may apply to all Android devices; I have no idea, and your mileage may vary ]:

  • Android automatically displays galleries based on image type — so you don’t need to update a database or anything to build your galleries on the phone. You just need folder(s) full of images.
  • When you run the Gallery app, it will display galleries with the name of the parent folder containing the images. This means you can make a folder tree on the Droid’s SD card and neatly package multiple gallery folders within it, without cluttering up your root directory.

Prepare the SD card

When I attach my Droid X via USB to the MacBook Pro, it automatically mounts it as a volume titled NO NAME, so I used the Finder to change the label to DROIDX. This, happily, seems not to have affected any of the phone’s operations; the Droid must not depend on the name of the SD card for any of its internal work.

The second preparation step is to create a master gallery directory on the SD card. This is just for housekeeping purposes; everything in the galleries will be in a subdirectory of that top-level directory. Again, I simply did this with the finder: navigate to the DROIDX drive when the phone is connected, and create a new top-level directory, Galleries.

Your SD card and Droid should now be ready to go.

Set up the Gallery/Galleries

Just like last time, I’m using smart publish collections, based on keywords, to populate the galleries that will be synced. I decided to prefix all the keywords for this usage with dx — so, dx-gallery is my main tag, and I’ve edited it in LR to not be included in export. It’s a housekeeping tag only.

I’ve tagged a bunch of images with the dx-gallery tag.

Then it’s off to build the publish service. Here’s what it looks like in the publishing manager:

And add to that service a Published Smart Set that looks like this:

You can assign multiple keywords to the Smart Set, or create as many smart sets as you want galleries, and use unique keywords to assign photos to each. Each smart set within the published collection will appear in your directory tree as a subdirectory of the top-level folder for the set — and that makes the syncing to the Droid easy.

Automate syncing via LaunchAgent

Everything I know about LaunchAgent I learned from this tutorial. This is basically a concise repeating of that description, edited for our purposes. (I’ve previously described using this process to perform system backups)

First, if it’s not already there, mkdir ~/Library/LaunchAgents. This is the folder that OS X will watch for scripts triggered by system events such as mounting an external drive, which is exactly what plugging in the Droid does.

In that directory, make a new plist file (I called mine droid-sync-watch.plist) and give paste this into it:

<?xml version=1.0 encoding=UTF-8?> <!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” \ “”> <dict> <key>Label</key> <string>droid-sync</string> <key>LowPriorityIO</key> <true/> <key>Program</key> <string>/Users/alan/Library/Scripts/droid-sync</string> <key>ProgramArguments</key> <array> <string>droid-sync</string> </array> <key>WatchPaths</key> <array> <string>/Volumes</string> </array> </dict> </plist>

In short, this plist file tells the OS to run the identified script (~Library/Scripts/droid-sync) when the specified WatchPath changes.

The sync script itself lives in ~Library/Scrips and consists of a check against the desired volume (here’s where naming the Droid SD card comes in) and an rsync of the designated published collection to the previously-generated target directory on the SD card.

#!/bin/bash # delay a short time to make sure the path is available echo -n "[*]-- new /Volumes... sleeping" | logger sleep 20 if [ ! -e "/Volumes/DROIDX" ]; then       echo -n "[*]-- DROIDX NOT connected - Exiting" | logger       exit 0    else       echo -n "[*]-- DROIDX Connected - Performing gallery sync" | logger fi # rsync with delete option rsync --delete -r ~/Pictures/Exported\ Photos/Droid/ /Volumes/DROIDX/Galleries echo -n "[*]-- DROIDX gallery sync complete" | logger

Finally, tell the LaunchAgent controller to watch your scripts by doing the following at a terminal:

  • launchctl load ~/Library/LaunchAgents
  • launchctl list | grep sync

You should see your droid-sync script appear in the list produced by the second command, above.

Now you’re ready!

Plug in and go

That really should do it. When you connect the Droid X, you can watch the messages in the sync script appear in your console log, and everything should work — after syncing, disconnect the device again and fire up the gallery application; in the “Folders” section of the gallery you should see an item for each gallery you create in Lightroom. You’re done!

As with the iPad workflow, the great part of this is that once it’s set up, it’s pretty automatic. If you edit, add, or remove photos, as long as you republish the collection, those changes will all be pushed over to the Droid. Thanks to a little nerdery and Lightroom, we’ve built a bit of functionality that the Droid software doesn’t directly offer — and it’s still done with LR as the core of the photo library.

Android / Droid X impressions

This little draft has been sitting unfinished becuase, well, life happened, so I thought I’d just throw it on up to get it out of the bin. These are somewhat organized thoughts about getting a Not-iPhone

So I posted this bit of a rant a couple of weeks ago about how Android just didn’t float my boat and etc. Well, not long after that I finally decided to stop waiting on a Verizon iPhone, and I ordered myself a Droid X.

Yes, the one described by David Pogue as like talking into a frozen waffle.

So how is it? Well, it is large, but it doesn’t feel like talking into a toaster pastry. I actually like the finish and feel a lot. The volume rocker is a little small, and the hard camera button is sloppy feeling. But the rubberized feel to the back of the phone is nice to hold, the ridge for the camera is a good contour, and the device overall feels quite thin.

Now that I’ve had some time to get used to the four hard buttons (menu, home, back and search), I’m pretty efficient at using the Droid X. I quite like the way the back button in some contexts returns to the prior application — for example, after visiting a link clicked in the twitter client, the back button returns you from the browser back to twitter. Search is application context-sensitive, and at the home screens it searches applications, contacts, and google. It also remembers prior searches, so it’s a handy way to launch applications or make calls, too.

However, the menu button can cause some complication, because applications don’t always use it consistently — worse, some create a soft button of their own that might or might not invoke a context menu. Here the iOS model definitely wins.

Keyboard: Text edit views often obscure UI elements, and small text boxes often are rendered as multiline text areas, taking up space rather unnecessarily. Fortunately, I have learned how to hide the keyboard after typing: since the Droid X keyboard doesn’t have a “hide” button like that on the iOS (and as I understand Android offers standard), swipe down from the top of the keyboard. That will re-hide it and give you back the rest of your UI. (That’s an undocumented Pro Tip, right there.)

Horizontal coverflow like display of bookmarks and images in gallery is awful. Really, it’s bad. Hold the phone vertically for a standard thumbnail-style view. (The same holds for the bookmarks view in the browser. In the faux coverflow style, bookmarks are entirely, entirely unusable.)

Lack of bookmarklets is regrettable. I hear there are workarounds that involve chanting and offerings to Shiva, so I’ve delayed exploring them.

Battery life: I have heard bad things about smart/app phones in general, including the Androids. It’s easy to imagine that Android’s true multitasking could be a big battery liability. This is where the fanboys go ZOMG APPLE SUXORS, but the presence or lack of multitasking hasn’t been an issue for me yet, in terms of functionality. I have observed that Android runs a lot of applications that i have not once, ever, run on my own — Amazon mp3 store and the car dock, for example — and this strikes me as a pretty inefficient thing to do.

So does it matter for battery? Who knows? After a handful of days I stopped using Advanced Task Killer every twenty minutes and just relaxed. While I reserve the right to revise and amend my statement, for now I’m very happy with my Droid X’s battery life: I routinely finish the day with 50 percent of battery life left on the meter after a day of pretty heavy use.

Apps I like (The range of Android applications seems … adequate if not impressive. The Android market badly needs some kind of curation.):

  • My Tracks: nice tracker app for biking in the hills. Integrates well with google maps.
  • Twitter app: Clean, works well, nothing extraneous.
  • Vignette: Much better than the built-in camera app, with a bunch of creative filters. I’m taking more pictures with the Droid X than in the past several weeks with my DSLR. Really good photo application a la the Hipstamatic app for iOS.
  • K-9 Email: This is a powerful email client with IMAP support. On the Droid X, there are lots of problem reports about the stock client not correctly refreshing, and while I am loath to solve a defect with an app, K-9 syncs properly and offers a bundle more features than the stock client.

It’s a good device with very nice hardware and some software feature that I really like — and some hitches.

More later?

Are these the droids you're looking for?

Marco Arment sums up my bemusement with the Android platform, and, by extension, why my frustration that that AT&T’s network is so awful where I live:

The current must-have Android phone changes every few months, and they’re often radically different from each other, making it difficult for consumers, developers, the press, and the carriers to build loyalty toward any of them or entrench them in the market. The OS needs to be updated over the air with three involved parties, only one of whom is motivated to update it. Features are added when they can be, not when (or if) they should be, or if they can be done well. Nearly every usability detail appears to be an afterthought, as if “design” is relegated to a coat of paint at the end of the development cycle rather than a deep-rooted philosophy throughout it.

The driving theme of the iPhone, as evident in every “There’s an app for that” ad, is “use this to do stuff.” Meanwhile, as near as I can tell, the driving motif of the Droids — with all the menacing Terminator-style chrome and unblinking red eyes — is that they’ll kill you if you aren’t careful. The tech-heavy “Droid Does” slogan reminds me of the days when Sega, hoping that more advanced specs would win the video game wars, tried out “Sega does what Nintendon’t.” And that turns out to have worked great for them, right?

The Verizon signal where I live is great, and I get a work discount, too. I simply can’t justify ditching that right now for AT&T’s extraordinarily mediocre signal, no matter how much I prefer the user experience of the iPhone. While there is precious little that actually draws me to Android, it’s a less dead end option than any other option that’s not an iPhone.

Ok, look. We've both said a lot of thing you're going to regret.



Brayden asked below about my experience so far with the iPad. Can it replace a PC for most uses? Put most simply, yup. I’m using mine for about 90 percent of the everyday time that I would normally spend on the MacBook Pro. In fact, it’s probably easier to write up the things that I’m not routinely doing on the iPad, these days:

  1. Lightroom: I do have a nice workflow for publishing photos to the iPad from Lightroom, but for now at least, that application itself still lives on the MBP. And Lightroom 3, by the way, has a host of improvements that I recommend.

And that’s about it. Now that I’ve had some time to get used to the keyboard, i can write pretty quickly with the iPad; autocorrect doesn’t always seem to catch things I think it should (like the lowercase “I” in the prior sentence), so i think about the Bluetooth keyboard once in a while, but I haven’t really needed more than the software keyboard. If i want to write a lot, of course, I can hop onto the laptop and TextMate away. (I drafted this article using on iPad.)

The iPad so portable and easy that I do a lot of sitting on the patio with it. It undersells it significantly to call it a reading device, but it’s so very good for propping in my lap with a coffee or a beer and diving into instapaper or the Kindle app. It’s just a thoroughly enjoyable experience.

Shortly after the iPad launch, some reviewer noted how it just gets out of the way and just becomes the application you’re using or the web site you’re visiting. That’s really a great way to put it, and it’s largely true. With a well done app, the iPad mostly disappears.

Here’s a short list of the good apps I’m spending time with (in addition to Safari and Mail):

  1. Instapaper Pro
  2. Kindle
  3. 1password Pro
  4. Twitterific
  5. Tab Toolkit
  6. Netflix
  7. Reeder

I’m still looking for a case for the thing (the DODO Case is mighty tempting), just for a bit more protection, though I’m not eager to cover it up, either. [Other recommendations, anybody?] And I don’t love the crop of text editors I’ve tried, so far, hence using for this post; the upcoming PlainText app sure looks good, though. But I have no true complaints. This is a super little device and I’m really having a great time with it. Don’t let anybody tell you it’s just a big iPod Touch.

Lightroom 3 to iPad gallery workflow

(Or, an efficient way to use Lightroom to manage photos on your iPad)

I got myself an iPad a few weeks ago. Short review: It’s a big iPhone only in the sense that an iPhone is just a phone; that is, it’s hawt and I love it. (More ZOMG iPad articles to follow, I’m sure.)

The iPad really shows off photos, so I’ve been thinking about the best way to manage the photos that I want to put on it. With the non-beta release of Lightroom 3 this week, I think I’ve found a start at a workflow in the new publishing service that it offers.

First a note about syncing photos to the iPad. Like the iPod/iPhone, you have to select a single parent directory, and optionally subdirectories, of photos that you want to sync. The iPad stores photos in a series of albums simply named after the subdirectory where they live on your hard drive. In my case, I keep the photos that I publish out of Lightroom in one of a number of subfolders of a ~/Pictures/Exported Photos directory, but I don’t necessary want to sync all of them to the iPad. And, for the iPad, I wanted a little more control over the album naming for purposes of navigation — so I didn’t want to keep the directory names I’ve previously used for simple file management.

So: I have an “iPad” directory in my exports folder, and that’s what I sync to the iPad — along with all its subdirectories. I’ve copied a handful of existing albums into that directory, which isn’t a great solution but it does work for now. Apple has apparently decided that symbolic links cannot be synced [that would be a great capability, wouldn’t it?], so I can’t simply create links to the file locations of the existing, non-Lightroom albums that I want to sync.

iPad sync directory; Lightroom 3 publish service directories are subfolders of this

But the Lightroom albums are another story. Right now, I’ve simply created a couple of Hard Drive publish services, each of which publishes to a subdirectory of that “iPad” folder I described above. For example, the current flickr one simply sets up a set of export parameters for photos that will be published to a subdir.

Lightroom 3 Hard Drive publish service setup

But the slick part comes by making a smart collection that will publish everything I post to flickr in 2010. Simply build the smart collection within the publish service:

Creating a published smart folder in Lightroom 3

And then set it to include all photos that match some key criteria: Since I use Jeffery Friedl’s flickr plugin, I can call directly on the metadata it creates at export:

Published Smart folder settings to include a subset of Flickr-published photos

I now have a smart collection within a publish service, so the photos that I export that match that criteria will automatically be added. I’ll have to occasionally republish to the service itself; and each time I do so, the iPad will gather up those photos the next time I sync.

You can use the same methodology to set up hard drive publish services for any album you like; each service will appear on the iPad as an album, and if you create a smart collection (or a series of them) as part of the service, then they’ll be updated automatically as you perform you regular photo workflow.

One final note on why I think the publish service is an ideal tool for this workflow, rather than a solution such as simply exporting to a folder: The publish service will apply future changes to the service settings to all photos under its control. So, were I to decide to apply a watermark, a border (via, for example, LR/Mogrify 2), or adjust photo quality in order to save space on the iPad, those changes made to the publish service would result in the option to re-process the current photos:

Publish service allows for the updating of all published photos when changes are made to the service

In a sense, then, the photos produced via the publish service are truly synced — future changes will be managed and will trigger re-processing, if I choose. I think that’s pretty Good Stuff.

About, the short version

I’m a sociologist-errant. This site is powered by Textpattern, TextDrive and the sociological imagination. For more about me and this site, see the long version.

Copyright and so forth: Commenters own their own posts, and linked or excerpted material is subject to whatever copyright covers the original. Everything else here is mine, rights reserved.

RSS feed