Federico Viticci

10804 posts on MacStories since April 2009

Federico is the founder and Editor-in-Chief of MacStories, where he writes about Apple with a focus on apps, developers, iPad, and iOS productivity. He founded MacStories in April 2009 and has been writing about Apple since. Federico is also the co-host of AppStories, a weekly podcast exploring the world of apps, Unwind, a fun exploration of media and more, and NPC: Next Portable Console, a show about portable gaming and the handheld revolution.

Sponsor: PDFpen for iPhone

My thanks to Smile for sponsoring MacStories this week with PDFpen for iPhone.

PDFpen for iPhone is the mobile version of Smile’s award-winning PDFpen for Mac. With PDFpen for iPhone, you’ll be able to make corrections and changes to PDFs, sign contracts and return them, or fill out an application – while you’re on the go.

I like PDFpen because it provides iCloud and Dropbox support, so you can edit your PDFs seamlessly on your Mac, iPad and iPhone. My friend David Sparks has created a series of screencasts for PDFpen, and the app is available at $4.99 on the App Store for a limited time.

Find out more about PDFpen for iPhone here.


“Open In” Is Not The Solution

“Open In” Is Not The Solution

Ben Brooks writes about iCloud and file management:

The only thing that iCloud really needs is an iOS style “open in” dialog for transporting files around. Add that dialog to all iCloud enabled apps and I can’t see any need for Dropbox if you stay within Apple’s “world”.

And this is yours truly, almost a year ago:

I think the same iTunes File Sharing feature would work a lot better as a dedicated, native iCloud app for iOS devices (and maybe the Mac too). After all, if Apple is providing an iTunes-based file management utility for Mac users, why couldn’t they build an app that enabled any third-party iOS app to save and import files from iCloud? This app would be built into the system and allow users to simply collect documents, like iTunes File Sharing. Developers could easily add options to their apps to import files from “iCloud File Sharing” and export files to it.

After a year of trying to rely on iCloud for document management, I’ve come to the conclusion that “Open In” is not the solution. The problem is still the same as September 2011: duplicates.

Decades of computing have shown that the filesystem is the single most complicated aspect of managing documents for the majority of users. People forget about “where they put stuff on the computer” all the time, and others keep simple levels of hierarchies because going deeper into the filesystem is, for them, annoying, “dangerous”, complex, or a combination of all these factors. In this regard, Apple’s “silo” model had a liberating effect: here are your documents, available in an app with a nice icon that you can immediately recognize.

However, the silo model – as opposed to the central “Finder” repository of files – has one big drawback: communication between silos. Therefore “Open In”: a menu that copies a file from Location A to Location B, getting from one document to two documents, now available in two different locations. And I would argue that the second most complicated aspect of managing documents is: figuring out the “right” version of a file.

Suppose you want to annotate a photo and save it in the Evernote app for iOS. You know that the iPhone’s Camera app sends photos with iCloud Photo Stream to the Mac, and they end up in iPhoto. From iPhoto, you know you can drag your photo out of Photo Stream and drop it into the Desktop, which creates a copy of the photo. Double-click it, and it launches Preview, which you know has the Annotate feature. There, you can add arrows and bold red text. Preview has this big iCloud library, but it doesn’t sync to the iPhone because there’s no Preview for iOS, otherwise you’d have used that instead. By the way, you’ve just saved the annotated image to the Desktop, but you can’t drag it back into Photo Stream on iPhoto because that’s read-only. Eventually you either give up and install Dropbox, start using the Evernote Mac app that you don’t like, or email the photo to yourself and use “Open In” or “Copy” from Mail for iOS to add another version of the file to Evernote.

You just used five apps and created four copies of a file (two of them are iOS Camera Roll + Photo Stream) to annotate a photo. Lather, rinse, repeat for note taking, PDF reading, electronic bill management, and assembling that nice slideshow of your vacation in Italy. Plus all those other things.

iCloud’s promise is powerful, and file management should be easier, but “Open In” is not the solution.

Permalink

1Password 4.1

1Password 4.1

A new version of 1Password for iOS has been released on the App Store, and it contains several fixes and improvements, including some that I suggested in my initial review of the app. Aside from sync improvements and Display settings (I can now set Inconsolata as my password font), I particularly appreciate the possibility to double-tap on a tab on the iPad to go back to root view, and search in portrait mode on iPad. It is no longer needed to tap & hold on rows on item view to show the popup menu, and tapping a secure note shouldn’t bring up the keyboard anymore (as I mentioned in my review, I found that behavior confusing). If you have attachments in secure notes, they’ll now be shown as well in version 4.1.

My favorite feature of 1Password 4.1 is the new URL scheme. There are two types of 1Password URLs: one for search, and another to quickly open a website into 1Password’s built-in browser. The search URL is: onepassword://search/ followed by your search string. You can easily configure this with Launch Center Pro’s keyboard prompt to automatically bring up a search for an item in 1Password starting from Launch Center Pro. If you launch 1Password via URL scheme while it’s locked, 1Password will obviously ask you for the master password first, then proceed to visualize results that match your search.

The URL scheme for opening websites is far more useful for me. You can prepend “op” to a normal Safari URL (so it’ll look something like “ophttp://”) to open it directly into 1Password. For instance, typing ophttp://google.com in Safari will launch Google in 1Password’s browser. Therefore, I made a bookmarklet that you can click in Safari to open the current website in 1Password even faster; simply create a bookmarklet with this code:

javascript:window.location='op'+(window.location.href);

…And 1Password will launch the website you’re currently viewing. I tested the bookmarklet in Safari and Chrome for iOS; it has become a huge timesaver to quickly log into websites that I access on a frequent basis.

There are many other improvements in 1Password 4.1 that make the app faster, more stable, and that fix some of the graphical glitches that I mentioned in my review. There are some subtle additions as well, such as different colors for digits and symbols in the password field when a cell is selected. 1Password is one of my must-have iOS apps, and make sure to check out the new 4.1 version on the App Store.

Permalink

App Store Screenshot Changes

App Store Screenshot Changes

Earlier this week, Apple announced a change in iTunes Connect for developers: app screenshots will be “locked” to an approved app, and developers may only change them upon submitting a binary for an update to an existing app (or new app). This has quickly been summarized as a way to slow down a popular tactic for App Store scammers; on the other hand, it also affects legitimate developers, who will now have to more carefully select app screenshots.

Craig Grannel comments on the change:

Users can now look at an App Store grab and be sure that’s the app they’re going to get. This means they will be more likely to trust the system and more likely to use it. That leads to increased income. The compromise: you can’t change your App Store grabs approximately every six seconds

This is one of those changes with consequences that are clearly visible and direct for those who follow development and App Store news, but more nuanced and indirect for the general consumer. Developers will find the change annoying, because it has become common practice to “tweak” screenshots even after an app has been released to highlight different features and/or include text overlays with quotes from positive reviews, and so forth. Now screenshots will perhaps be treated more like app icons, which have to be chosen and studied carefully upon submitting an app. Developers now have less chances to “get screenshots wrong”, unless they want to submit an app update to fix them.

On the flip side, this is the kind of news that average users won’t care about. The billions of App Store downloads are made by people who have no clue about scamming strategies and who definitely don’t read Apple’s developer news. They trust Apple to provide a quality App Store experience, they don’t know about the inner workings of iTunes Connect. This screenshot policy won’t be directly noticed by consumers, but it will help Apple provide a better experience by crippling a common trick scammers used to sell one app for another.

What’s the solution? Enabling a “trusted developer” tier could be an idea. But then again, how does Apple determine “trusted developers”? By making them pay more, or by manually selecting companies they know and trust? And if the latter solution is feasible, how can a kid with a legitimate idea become “trusted” if he has no connections at Apple? Should there be a “request verification” process? And so on.

As the App Store grows bigger and older, dealing with thousands of sellers will become harder for Apple; sooner or later, they’ll have to face the fact that the current App Store infrastructure wasn’t built for a million apps. That is already true for search and curation. Trusting more and more developers is just another consequence of growth.

Permalink

Empty States

Empty States

Craig Dennis on area of app design that gets often overlooked:

Empty states are places in apps that have no content or data. They are empty. A blank page. Traditionally empty states are overlooked as most designers focus on how best to display lots of content or data. It’s common for empty states to be dealt with by developers as they are often caused by exceptions (such as no internet connection). They often write the copy and as a result it can be a little difficult to understand or it is left with the basic styles. Not the best combination. It should be logged as something that needs designing but that doesn’t always happen.

It gets even worse with apps that deal with errors through text that isn’t localized. In fact, I’d argue that proper localization is another aspect of the app economy that shouldn’t be underestimated anymore (as if it ever could be): with apps available in more than 150 countries, designing for the US market alone is a foolish assumption (unless, of course, an app’s only market is in the US – which is the case with many online services these days).

Empty states can be useful and provide context. Whether it’s a way to instruct users on how to get articles into a read-later app or a cute illustration with a link to How-To pages, empty states should find a balance between their lack of content and presenting on-screen guides.

Permalink

Pushpin for Pinboard

MacStories readers know that I’m a fan of Pinbook, a Pinboard client for iPhone and iPad. For the past two days, I’ve also been trying Pushpin, developed by Aurora Software, and I’m quite impressed with the feature set the app has reached at version 1.3. Pinbook and Pushpin are, ultimately, very different, and I believe their current versions can coexist on a Pinboard nerd’s iOS Home screen. Read more


Launch Chrome Bookmarklets With Keyboard Shortcuts

A few weeks ago I switched back from Safari to Google Chrome. I wanted to give Safari a fair chance, especially after the introduction of iCloud Tabs, but, alas, the browser never “clicked” for me the way Chrome did. Worse, using Safari on a daily basis for work-related tasks became an unsafe bet, as it was crashing too often, taking several minutes to sync my iCloud Tabs, or generally hanging for no apparent reason. I’m still figuring out the ins and outs of Chrome – particularly how to handle the lack of a “default browser” option on iOS – but, so far, Chrome is working better for me.

One thing I miss from Safari is the ability to launch bookmarks in the Bookmarks Bar with a simple CMD+1…9 keyboard shortcut. I use a lot of bookmarklets (which, by the way, Chrome syncs faster than Safari across devices), and I’m too used to hitting CMD+2 for OmniFocus and CMD+4 for Pinboard to give up the convenience of quick bookmarklet activation. Unfortunately, Chrome uses Safari’s CMD-based shortcuts for switching between open tabs.

The solution was laying in my dock the whole time. As cleverly shown by Patrick Welker, you can use a Keyboard Maestro macro to assign a keyboard shortcut to what is, essentially, Keyboard Maestro’s own GUI scripting, only done with a visual workflow. Make sure to read Patrick’s post to see how you can create a simple macro to “click” a bookmark in Google Chrome.

For the non-Keyboard Maestro users, a solution is to actually use AppleScript GUI scripting to simulate clicking a bookmark’s name. Using something like the script below, you can use any launcher that supports assigning a keyboard shortcut to an AppleScript to quickly launch a Google Chrome bookmark.

tell application "System Events"
    tell process "Google Chrome"
        click menu item "pin" of menu "Bookmarks" of menu bar 1
    end tell
end tell

The script could use an error-checking system to see if Chrome is the frontmost application, but I avoided adding it because I know I won’t use the shortcut anywhere else.

As for Chrome on iOS: because the browser forces you to type out bookmarklet names to launch them, my suggestion is to use a standard prefix so you’ll be able to launch them easily from the iOS keyboard. For instance, I prepend “xx” to my most used bookmarklets, so Chrome for iOS will filter the names right away.


Igor Cheban’s iPhone Paintings

Igor Cheban’s iPhone Paintings

Self-taught, 21 year-old artist Igor Cheban has posted on Reddit a gallery of his collection of iPhone paintings. Igor’s impressive work, available here, is the result of hours of work done primarily on an iPhone, with a few “paintings” created on the iPad (such as the “Wabbit” one in the link above). In the Reddit thread, which received hundreds of comments thanks to the exposure granted by Reddit’s homepage, Igor explains how he used award-winning iOS app Brushes to create the paintings (finger-painting with Brushes isn’t new to the Internet).

In particular, two comments stood out to me, as they epitomize the advantages and drawbacks of digital painting:

Very similar to digital painting on the computer. Although computer and real life painting allow you to control the flow of the lines by adding pressure which the phone is not capable of doing. So that’s something to consider. I do like the unlimited undos that digital painting offers so I would say that is the easier one.

when I’m working on a digital painting and I love the idea (for example “bird slayer”) then I feel just as excited as I would working on a physical painting… However, something wonderful about possessing a physical piece of artwork once finished. Unlike a digital file which could easily be reproduced, only one true original piece can exist.

Preservation of digital media, either in the form of text or images, is something I, and others, have been advocating for a long time. The topic resonates with iOS users: with apps that enable the most variegate kinds of creations, how do we ensure they can be stored and archived for future memory?

Make sure to check out the original Reddit thread and Igor’s profile on Instagram, where he uploaded more iPhone paintings and other sketches. He also posted a video on YouTube showing the techniques he uses with Brushes, mainly zooming in/out of the canvas to draw details and get the full picture. Brushes is Universal and free on the App Store.

Permalink

Favs for iPad

Favs for iPad

After months of silence, Dirk Holtwick is back with a Favs update (version 1.2) that brings iPhone 5 support and a native iPad version. For those unaware of Favs, it’s a Mac/iOS app that collects your Internet favorites (“starred” or “liked” items) from sources like Twitter, Google Reader, Instagram, and more. From my review of the iPhone app:

Released yesterday, Favs for iPhone is a $2.99 mobile companion that serves the same purpose of Favs for Mac — it offers a unified interface to browse favorite items from multiple sources. The main screen features three general tabs for All items, Inbox, and Archive. However, I never use Favs’ own read/unread indicators, because I don’t want to “feel the guilt” of having too many favorites in my accounts. For this reason, I am glad Favs for iPhone lets me hide unread counts from the Settings, which also reveal iCloud sync will be coming soon to keep account information synced across Mac and iOS devices. I very much prefer to browse favorites by their original source.

The iPad app is an addition to the existing app, which is now Universal. It’s not revolutionary in that it takes the iPhone app and puts a list of accounts and favorite items in a sidebar on the left, with a larger panel on the right to view content. There are options to turn on Readability, and an action button to email, tweet, or copy a URL, or open a webpage in Safari. iCloud sync worked on first launch for me – it pulled some of the accounts I had configured on the iPhone – but I would like to see more options added in a future version (hopefully not in six months) such as Google Chrome support or a URL scheme to launch specific accounts directly.

Favs is available at $2.99 on the App Store.

Permalink