[Editor’s Note: When we last left Dan Moren, he’d survived day one of his iPad experiment, in which he vowed to use nothing but his tablet to get his job done for three days. Now we move to day two.]
While day one had been an adjustment, things had gone pretty well; I hadn’t needed to resort to my Mac at all, and I had finished my work on time. But, to be honest, I had been a bit cautious about the things I’d attempted to do. So on day two, I pushed myself a little bit harder. Not surprisingly, in doing so I ran into more problems.
For example, on the morning of day two, I was assigned to manage the news desk. That means keeping an eye on news, assigning stories, and letting readers know about new stories via Twitter and Facebook. But when I fired up Twitterrific () on my iPad to tweet about that morning’s stories, I ran into a wall.
On the Mac, I use an AppleScript to generate short links to my stories with a tracking tag; the iPad doesn’t support AppleScript, so that wasn’t going to fly on the iPad. Fortunately, my clever colleague Lex Friedman came through, adapting a JavaScript-based bookmarklet so that it would not only create the short URL, but even fire up my iPad’s copy of Twitterrific and prepopulate a new tweet with the URL—making the process arguably even easier than it was on my Mac. But be warned: If your workflow depends on AppleScript, you’ll need a workaround on the iPad.
Later, while editing a column, I needed to insert some boilerplate text at the end. I could have turned to an iOS app such as TextExpander (), but I find that awkward. I opted instead for a low-tech solution: I kept a text file of my snippets in a text editor, and then copied and pasted them whenever necessary.
Later in the morning, though, I encountered a problem I couldn’t circumvent. I wanted to upload a picture to accompany a story, but the iOS version of Safari wouldn’t allow me to. (That functionality requires access to the file system, which iOS doesn’t grant—even to Apple’s own browser.) Instead, I was limited to searching through the database of already-uploaded images.
As part of my desk duty, I also had to prioritize assignments in the story management tool. Unfortunately, that tool uses a drag-and-drop interface that just doesn’t work with a touch-based device. (The problem has to do with the JavaScript library the system is built on.) To my chagrin, I had to ask one of my colleagues to do the dragging and dropping for me.
Into the cloud
I had set aside time during the afternoon of day two to work on a story I was cowriting with a colleague. Thanks to a number of Web services, such collaboration is easy these days. When on my Mac, I use a free program called Cloud to quickly upload screenshots and send links to them to my colleagues. So I was glad to find that there are a few iOS Cloud clients; I picked up an excellent one called Stratus, which let me easily upload files and generate links to them. It turned out to be one of the handiest new apps I discovered during the entire experiment.
However, not all Web services treat the iPad like a full citizen. For that collaborative story, for example, my colleague and I turned to Google Docs, a tool we use all the time at Macworld. Unfortunately, I discovered that the Google Docs interface on the iPad leaves much to be desired.
For one thing, you’re forced to use a slimmed-down mobile version of the site, which lacks many of the full version’s features—most importantly, real-time collaboration. Instead, you must constantly tap a Refresh button to synchronize changes you’ve made with the copy in the cloud. When you’re writing alongside a colleague or colleagues, that’s an inconvenient extra step, to say the least.
I ended up tabling the effort until I got back to my Mac. It was one test that the iPad really and truly failed.