I am a big believer in cloud storage services like Box and Dropbox.  In fact, for over a year and half now, I’ve had pretty much all of my data in the cloud. That move was triggered by 3 things :

(1) increasing number of devices I use (at last count, a tablet, 2 phones and a computer) 

(2) collaboration with other folks & my team, mostly around documents 

(3) a desire for simplicity - not wanting to deal with my files scattered in multiple places and keeping track of where the master copy was, while trying to achieve (1) and (2). The less I worry about the mechanics of data storage, the more efficient I am as I can get the technology to disappear. 

Side note - growing storage capacity is a plus, but not a driving factor. Although, having all my data everywhere I go is an added benefit; much better compared to the solution I used back in undergrad days - carrying around a 10GB internal hard disk to avoid having to deal with perpetually-unstable floppies, and write-once CD’s! Yes, I do have some underpinnings of a computer geek.

The ‘App’ based approach

Most of these cloud services have taken an “app” based approach on integrating with devices.  It works something like this:

- You download an App (on mobile or desktop)

- the App gives you access to your cloud data, and allows you to download/upload files

- On desktops, the App will typically run in the background and keep your files synch’d with the cloud and you access them as you would any other local file

- On mobile devices, the App (or embeddable SDK) allows 3rd party apps (like a Mobile Office suite, for instance) to access & manipulate the files stored in the cloud. 

Why do we need an integrated approach ?

While this has been a quick and easy way to get into the market, I believe that mass-market adoption and the next inflection will come with an improved user experience.  

Here are the major challenges I face when dealing with cloud storage services -

- Collaborating with others, I still end up with some files scattered across different cloud services. Plus, I use different apps to access and edit them. 

- Hence, I have to deal with providing almost every app my cloud storage credentials  and dealing with their crappy user interface to pick files. 

- And when I’m done editing them, I have to remember to save them back in the exact same location where I ‘copied’ them from.

An ‘integrated’ approach is one way to improve the experience.

What does an integrated approach look like ?

So, how should it be ? Ideally, the integrated cloud storage UX looks something like this, with the OS (mobile and desktop) providing cloud storage as an extension of the file system. 

- Integrated Credentials: I dont want to provide my Dropbox or Box credentials every time I use a new App. I want to provide it once, to the OS, and then give Apps “permissions” to access my files as I use them.

- Integrated File picker: I should be able to launch any App and be presented with a consistent User interface to access and deal with files. Across cloud storage services. With search capabilities.

- Integrated File sync: Don’t make me save the file back to a specific cloud service. When an App saves a document, it gets automatically synch’d to the cloud and available on all other devices. Without me having do anything else. 

As an example, iCloud integration on Mac OS & IOS is a good first step. Now it just needs to be followed up by allowing for 3rd party cloud sync service integrations. Do it the same way Facebook and Twitter are now integrated into the OS. Extend the iCloud file picker to include files from other 3rd party services, and give me a way to search for them.

Who should be doing it ?

One might argue that this can be pulled off by cloud storage providers themselves or aggregators like Filepicker.io. Maybe. I believe it depends on the platform, because that’s where things come together.

On mobile and desktops, that platform is the OS. And there, the biggest impact & reach happens when Apple or Google or Microsoft do it, because

(1) they can drive a better UX because of what they can do under the hood, and

(2) they’ll do it for free. 

Plus, it’s in their best interests. Dealing with files is one of the most common tasks when working with computers, big or small. Make it a pleasure, and technology disappears, but you get to continue playing the game. Make it a pain, and the guy who does it right, gets ahead.

The wild-wild-web is a wild card. The lack of a ‘platform’ implies that we continue to see implementations like the Dropbox-Asana integration. Dropbox, Box and probably others will (eventually) have reasonable although silo-ed implementations of an “integrated” approach. However, as much as they’d like me to just use one service (their’s), it’s not going to happen, and hence there’s a technology play in something like Filepicker. The question is, as a developer, would you pay for a service like that ?

What’s your take ?

On a related note, the general theme around well integrated 3rd party services applies to the Internet-of-things/Connected devices space as well, one that I expect to be writing and acting on a lot more in the days to come :). 

Over the past weekend, a close group of tech savvy friends & I spent some time discussing Apple & Google over a rather long drawn out email thread. Beyond the usual talking points (& how Jobs was irreplaceable - funny how that always creeps into every discussion about Apple), it got interesting when the discussion got me (re)thinking about design vs data.

Apple’s strength is design. We’ve seen it at work on physical products and software. Google’s core strength is data, algorithms & in it’s own words, information organization. But design is art, and by extension subjective. Which is both good and bad - good because it’s difficult to achieve, and bad because (I believe) it’s no longer enough. 

Winning in the next 5 years is going to be about moving from design driven UX to design + data driven UX. Case in point : Siri vs Google Voice search. I loved Siri when it launched.   It was well integrated into the iPhone, reasonably accurate and offered a good UX. I have now switched over to using Google Voice search almost exclusively for Places. I didn’t think twice about this impact of data that was powering it. Until recently, with the Apple Maps snafu and introduction of Google Now. 

(1) Google’s voice input implementation is far superior to Apple’s. Voice input on IOS is speaking into a glowing microphone and waiting to Apple to translate it to text. Voice input on Google’s search app & Android devices is translation as-you-speak. That instant feedback is simply awesome. And it’s more accurate. Why ? Data, collected using their 411 service & Google voice. A perfect example of data driving UX.

(2) Ever since Siri moved away from using Google for it’s places search, the quality has gone down. And it used to be awesome. Earlier today, I searched for “Specialty’s Cafe near Ellis street”. Siri apparently  misunderstood me. And Google’s app showed me the Specialty’s cafe in Mountain View. Another example is captured in the screenshots below.

At the heart of all this is data. And without the data, UX is crap. To continue winning, Apple will need to step up it’s data game. And this isn’t just about Apple and Google - it applies to virtually all products and experiences we design.

Triggered by a discussion thread in a private founder group I am on, I started thinking about how a startup founder could think about the crowdfunding landscape. Here are my thoughts.

Crowdfunding through product sales (Kickstarter style)

Kickstarter projects leverage crowdfunding through getting customers to pre-pay for a purchase or donating to a cause they believe in, and not with a financial investment mindset. The purchase/donate mindset is likely to work when you are going to sell a product directly to the “crowd” (whatever that segment is). Hardware ? Yes. Software monetized by product sale or subscription ? Likely (case in point, App.net). Products monetized through other means (like advertising) ? Tough to pull off, unless you have a strong community that believes in the idea.

As evidenced by success of projects like Pebble, crowdfunding with product sales has become a viable alternative to VC capital for financing the development of hardware projects. In addition to being a good proxy for public demand for the product, the advance-sale model that these projects adopt helps them raise the money to get the manufacturing process rolling. I see this as a great way for hardware startups to validate the idea before investing money in actually mass producing the product, and to show traction for a follow on professional investment. 

App.net has applied this model to a software product. Appbackr is a platform that enables this for mobile apps. For software, however, I see this as more of a way to generate early customers and some traction rather than financing early development (the financial requirements generally being low enough that they shouldn’t really be a concern). I expect to see more crowdfunding-for-software platforms opening up in the near future; I think someone like Betalist would be perfect for enabling such a platform for web services.

Equity/Debt investment by Professional investors vs Crowdfunding

The discussion in the group I referred to earlier was looking at crowdfunding (JOBS act) as an alternative to raising money from Angels/VCs. The general sentiment was that angel/VC is a better route for most software startups primarily because such investors bring more than money to the table; feedback, intros, help with product/recruiting/future fundraising, etc. Another argument is that startups that take a crowdfunding approach will see larger cap tables that deter professional investors from making follow on investments. And because of the largely uneducated nature of the crowd, instruments like convertible debt are way too risky to manage.

I am inclined to agree. But, I think there might be a way for both to coexist.

I find it difficult to see direct ’crowd’ investing in startups to be sustainable. A ‘crowd’ investor has limited understanding of how startups work and the metrics to measure their success (and although platforms like Angellist can evolve to bring transparency to sharing metrics, interpreting them is still a subjective game). With direct investments, there will undoubtedly be folks who lose money, and due to lack of education & portfolio diversification typical of non-professional investors, this will translate into disillusionment. 

The likely scenario is that someone forms some equivalent of a hedge fund that then invests in such startups. ‘Crowd’ investors can then invest in such a fund instead of investing directly. With such an approach, the cap table will probably be small enough and a startup doesn’t have to deal with the risks of having numerous small investors, while benefiting from the increased capital available to go around. 

Thoughts ? Opinions ? 

Aperture iPhoto Sync is an applescript which will sync your Aperture projects/albums to iPhoto, thereby making them available to the rest of iLife apps for you to use. (Yes I know that you can drag and drop Aperture images & create iPhoto albums, but a script sure beats doing this manually!) It syncs masters by creating links in iPhoto library to save space.. and (optionally) syncs up modified versions by exporting them using Aperture’s export presets.

Note : This post is a part of migrating my old blog over to Tumblr. I worked on this a while back, but hopefully, someone still finds it useful.

Also : The script hasnt been updated for Aperture 3 yet, so if you’d like to use it with A3, please feel free to update and let me know :-).

UPDATE: See below for a version that works for Aperture 3.

Features

• Syncs Masters without copying them – save space !
• Syncs modified versions by exporting them from Aperture using selected presets.
• Will optionally delete photos from iPhoto albums before syncing – ensuring an exact replica.
• Syncs intelligently – ignores ‘Rejects’ and syncs only ‘Select’ of a stack to avoid clutter.
• Uses the library that you have configured in Aperture as the the library it imports from.

First run….

The first time it is run, it will prompt you for certain defaults for it to use henceforth. These values include :

• Whether to Export or Ignore modified photos or ‘versions’ from Aperture while syncing. Exporting modified photos to iPhoto will take up more space since duplicates of the existing versions in Aperture will be made. This also takes up more time to sync.
• If exporting, the Aperture Export preset that will be used by aperture to export the photos.
• Whether to delete photos from existing iPhoto albums (with the same name as the Aperture project/album you are syncing up) before adding photos to it. Selecting this option increases sync time by a bit, but will ensure that the iPhoto album is a replica of your Aperture album/project.

These preferences are stored in the file ~/Library/Preferences/com.devarshi.ApertureiPhotoSync.plist. To change these preferences, either edit the file using plist editor, or delete it. If the script does not find the file, it will prompt you again for the preferences.

The sync….

Using the script is pretty straightforward.

• When run, the script will present you with a list of folders and projects from Aperture that you may choose from. Currently, this script allows you to select only one folder/project at this level.
• Upon selecting a project/folder, the script will present you with a list of projects/albums contained within it, from which you may select one or more.
• If the first selection does not contain any projects/albums, the script will check to see if it contains any images itself. If so, the script shall create an album in iPhoto with the name of the selected project in Aperture and import those images into that album according to the defaults selected earlier .
• If, in step 2, you were presented with and selected one/more sub-projects/sub-albums, the script will then proceed to create albums in iPhoto with the same names as the selected sub-projects/sub-albums and import the images into those albums according to the defaults selected earlier.

A few tips…

• If you choose to “Export” modified images from Aperture, do note that this takes up some amount of time during which, apparently, nothing seems to be happening… This is because Aperture performs a background export of the images… If you don’t believe me, check your CPU usage !
• The “Export” of modified images creates temporary photos. After each project/album is imported into iPhoto (copies of these temporary photos are made in the iPhoto library), these temporary photos will be moved to trash. So, if you plan to ‘export’ a lot of photos, make sure you clean up your trash periodically !

A few things to note…

• As of version 2.3, the script needs your Aperture library to have atleast one stack for it to run correctly. It will fail in between if you dont. While I work on this problem, for the time being, please create atleast one stack in your library.
• I’ve done some basic tests with Aperture 2.1.2 and iPhoto ’09. (Do not use this version script for Aperture versions prior to 2.0 or after 3.0).
• Please note that this script is still in alpha stage… so please backup your libraries before attempting to use this script.
• I currently do not have a lot of time to test this script extensively, and so am posting it here hoping that it’ll be useful to others, and that I can use your feedback to fix any issues…
  
• However, if you run into any problems, or if you have any comments, please feel free to get in touch with me or leave me a comment here.

Updates for Aperture 3.0…

Note : Michael Rest was kind enough to share his changes to the script to make it compatible with Aperture 3.0. I’m including his version of the script here for folks to use. I will be integrating changes from his version into my release after I’ve had a chance to test them.

Please contact him if there are any issues with the script since I havent had a chance to test it.

Change List:

• - Updated to Aperture 3 : Fixed Paths, Tablenames, SQL Statements
• - Fixed deletion of exported temporary Files
• - Fixed temporary items folder
• - feature changes marked as [MiR]
• -Modified seection Process:
•   * Select Projects from Root Folder (Library Folder)
• * Select Folders from Root Folder (Library Folder)
•   * Select Subprojects / Albums in Folder
• -Modified behaviour just to export Pics:
• * rated from 1 to 5
• * flagged
• -Disabled GetListOfPathsToImageMasters because i always want to export my Versions (Masters all RAW in IPhoto i only keep resized JPEGs)
• -Default PrefDeletePhotosInAlbumBeforeAppend changed to true

Download v3.0 of the script here (Updated to work with Aperture 3 by Michael Rest)

Download v2.3 of the script here (does not work with Aperture 3 yet)