Filepicker.io Blog

Filepicker.io helps developers connect to their users' content.

Connect your web/mobile application to Dropbox, Gmail, Facebook, et al. plus dragdrop, image conversion, and upload acceleration.

After being awarded as “Best Plug-In of May” by Atlassian, we used this excitement to add a linking feature to the plugin. With Version 1.1, you can link files from any of the cloud sources which host files and stop worrying about keeping JIRA in sync.

Check out the video here

Check out the newest version of the plugin here

Over the past year, we’ve gone from a single javascript widget to a full suite of products that help over 20,000 applications connect, process, and store over 400 million files each month. As the company and products continue to grow, we wanted a name that could grow with us, and so are announcing the new name of the company: Ink.

For our customers, we are still committed to offering the best possible products and support, and so we are making this transition in a way that does not require any changes on your part. Everything will continue to work as is was before, but we recommend that you go to http://developers.inkfilepicker.com for documentation and your developer portal rather than http://developers.filepicker.io. Existing filepicker.io urls (like https://www.filepicker.io/api/file/35gJ6mY5QgyBTHkfxk96) will continue to work as is.

As we take this next step as a company, we want to thank the Ink developer community for their continued support, and are excited to continue building the products and services that will help people and software work together.

Recently we released our Filepicker JIRA Plug-In to enable JIRA users to attach files, select profile photos, and export records using all Filepicker supported cloud sources.

The way organizations are consuming software is radically changing. Consumerization of enterprise IT is emerging as the dominant model for software adoption. Atlassian’s products: JIRA and Confluence are leading the charge on how software organizations manage their processes ranging from bug tracking to collaboration. When we looked around we saw that many users inside organizations are using services like Dropbox, Box, Evernote, Google Docs, GitHub, etc… and that it’s very painful to import those files and doucments into JIRA on laptops/desktops and near impossible on mobile devices. A lot of our customers are heavy JIRA users and kept requesting us to add a way to connect Filepicker.io and JIRA. So we naturally extended our APIs to end users of JIRA via this plug-in.

We made it a strong focus to keep the user experience consistent so that there are no new learnings needed on the end user’s part. Equally important, we focused on making the life of the administrator simple by allowing them full control over which actions are overridden by the plug-in, and which sources/destinations are available to their JIRA users.

Here is a demo of how it works.
http://www.youtube.com/watch?v=FVMfp9vhRKo

We hope that those of you that use JIRA will check it out and let us know what you think. If your JIRA admin has any questions or comments, we would love to hear back from them at contact@filepicker.io.

Check out the plug-in in the Atlassian Marketplace.

Thanks!

Express your ideas with conviction, but be willing to drop them and adopt better ideas as they come along. The best leaders and organizations are those that are pragmatic. Here at Filepicker.io, we say “Strong Opinions, Weakly Held” - a concise and effective way of encouraging active debate and the meritocracy of ideas.

“Strong Opinions” means two things: that you should express your ideas with conviction, and that those opinions should be strong opinions, supported by evidence and logical. If you don’t express your opinion strongly, it may not stick in the listener’s head as well as an overall weaker idea that someone else expresses with more zeal.

“Weakly Held” means that if a legitimately better idea is presented, embrace it and change your stance as soon as possible. This is often referred to as “check your ego at the door” - there is no honor in continuing to fight for an opinion just because you expressed it previously.

It is not uncommon for people here to be passionately arguing a feature, a design, an architecture, and for one person to suddenly stop and say “oh - yeah, you’re right. Cool. What’s next?” This can be unnerving to people who experience it for the first time, but it’s been very effective in sifting out the best ideas and facilitating a culture of health arguments and deep mutual respect.

Discuss on HackerNews

We’ve been growing in headcount and we found ourselves with an odd problem: we didn’t have enough key fobs to the office. Filepicker.io moved into a nice work live space overlooking AT&T park last October and our landlord has been great; we just kept asking for more key fobs. However, here’s how we got Twilio to open the door for us. [1]


image

The door, like many live/work spaces, has a phone box. There is a list of names and corresponding numbers. Dialing the right code rings the resident and the door opens when they press ‘9’. We’re going to integrate with this existing system to allow our code to interface with the door.

Solution

The system is straightforward. Text a number when you’re about to reach the office. [2] If your number is on the server’s whitelist, it will be expecting you to arrive in the next 5 minutes. Then punch in the number of the office and Twilio will let you in. If the door isn’t expecting one of us, it will simply forward the call to one of us.

There’s also a party mode, where you tell it to let anyone in. No more having the host keep having to answer their phone to make sure everyone gets in.

Security

We considered other security models as well. Taking a look at how people ensure that they aren’t letting random people in is by verifying the name, voice, and if they are expecting them. Mimicking that would be difficult, both due to the voice recognition (had a tough time finding good libraries for voiceprinting) and arrival expectation (based on people’s Google Calendar?).

Our phone system didn’t seem to forward DMTF tones from the phone box so we weren’t able to use a PIN number.

We also considered a location based phone app that would open up the door whenever you got near it. However, given that our offices were right above the door, it’s difficult to distinguish between one of us sitting at our desk and one of us waiting outside.

Infrastructure and Code

Infrastructure-wise, we’re running it on a AWS Micro and an elastic ip, though Heroku works as well. [3] You can set up your own doorman as the source code is here and Twilio is super easy to set up. You’ll just need to ask your landlord to change the phone number to your Twilio number.

We’re open sourcing our code and you can get it here, with relevant setup instructions: https://github.com/Filepicker/gatekeeper

It’s pretty simple code, but the configuration management is worth mention. We wanted it to be highly configurable, but didn’t want to write a web or curses interface. Instead we opted for a YAML backed dictionary. Modify the file and the next time the app needs the data, it will reload the config. If you made a typo and the yaml parsing fails, it won’t crash. It will just continue to hum along with the previous configuration.

It’s been rock solid for us (it’s pretty easy to be bug free with <100 lines of code) but pull requests and suggestions welcome.

This probably shouldn’t be used to protect Fort Knox, but it’s a good system that has allowed us to grow and scale out the team here at Filepicker.io. Startups at our stage all have growing pains, both those that you’d expect and those you wouldn’t. Migrating your db to SSD’s is one you’d expect. Migrating your door off of key fobs, not as much.


[1] This was also a flyout interview project. Double bonus.

[2] You can also have Siri send the text message for you, ala http://rumsey.org/blog/2011/11/voice-controlled-garage-door/

[3] I haven’t experimented to see if the single dyno sleeping will serious impact the code. You may need 2 dynos.

Hi all,

Monday the 1st I joined Filepicker.io to work on User Acquisition and Product Management and I am pumped!

Prior to this role, I worked as a Product Manager of Shopping and Merchandising at Nook (the e-reader owned by B&N) in Palo Alto, Product Manager of League of Legends Shop at Riot Games in Santa Monica, and as a Program Manager on System Center at Microsoft In Seattle. Through these roles I acquired a good amount of knowledge in the areas of eCommerce, Merchandising, Personalization, User Experience, and Enterprise IT Solutions (can you spot the one that comes from Microsoft?). I very much enjoyed defining and building product and look forward to incorporating that knowledge and experience as well as extending my knowledge to identify and address any needs which help with driving healthy adoption of the product.

The largest driver of my fresh excitement stems form the fact that the company, the role, and the space are very young and ripe for innovation and definition. We are again in a position where we are experiencing a paradigm shift like the introduction of the OS, web, mobile, social which I call the interoperability paradigm (until someone comes up with a better name) where developers of end user solutions switch from building their own way of doing everything to adopting services that give you a majority of your applications functionality without having to develop it yourself. Examples include logging in with Facebook, Google Analytics, Ad Platforms, and of course Filepicker! Chances are very high that your application does not specialize in uploading and downloading files and hence any time you spend building those features is time you don’t spend building your magic sauce. Or you can not provide these features and force your users to peck around the web for their files and hope they don’t get discouraged enough to stop using your service. You can think of this space as having two dimensions, horizontal interoperability is something like Filepicker where you get extra functionality which you don’t have to build. Vertical interoperability is for example using Mongo DB instead of building your own. Vertical interoperability has been around for a while and is seeing great adoption at this time, and horizontal is just getting of the ground floor.

My personal definition of success in my role is delighted users. This means that your users are happier with your service because of our service to you. If that is the case I go home happy, if that is not the case, I don’t go home. Here are some principles by which I tend to do my work:


1. Having a small user base that loves you is better than a large users base that thinks you are mehhh, ok…
2. Our product is our best salesperson.
3. An authentic representation is important. You as the community should be informed about all the good and bad of our product or service and kept up to date on improvement and issues in the service.

With these principles in my pocket I hope to provide the best developer experience for our developer community and user experience for their customers. I am sure I will communicate much with many of you and I look forward to that.

I am one of those people that does a little bit of everything when it comes to hobbies, and it changes frequently. Currently I go bike, hike, read, sip lattes, and watch Battle Star Galactica (almost done!).

I hope to meet many of you in the future,

Darko

One of the most requested features we hear from our customers is the ability to use video transcoding with Filepicker.io in a way that’s just as powerful and easy to integrate as our image conversion capabilities. We took a deep look at the video transcoding space and knew that we wanted to work with Zencoder to make it happen. The result? The easiest way for your application to collect, transcode, and display videos to your users.

Here’s how to get Filepicker.io and Zencoder working together in your application (or just see the demo and source code):

0. Head on over to Filepicker.io and Zencoder to sign up for accounts if you haven’t yet - keep your API keys handy, you’ll use them soon

1. Pull together the basic html template:

2. Add the custom javascript to call Filepicker.io when the upload link is clicked

3. Add the logic to take the upload and send it to Zencoder’s servers for processing

For a full tutorial on using the two services together, see the tutorial and the accompanying demo, along with accompanying source code on github

We’re really excited to see what you all build with this new partnership - whether your users upload videos for their profiles, a product review, a crowdfunding project, or really anything else, Filepicker.io and Zencoder can help you make it happen.

A special thanks to Matthew McClure and Casey Wilms at Zencoder for their work to make this possible.

Discussion on Hacker News

When you’re working on javascript code, you can set a breakpoint from your editor by putting in the statement ‘debugger;’ in your code where you want to break. It’s better in many cases than manually setting a breakpoint in the inspector.

I recently was working with a very talented front-end engineer who had never seen this trick, and so wanted to share it with the subset of javascript engineers out there who for whatever reason have never seen this. Put it in your code where you want to break, open up the web inspector, and the code will stop where you commanded, allowing you to walk the code forward, inspect the stack, and get and set local variables at will.

(function(){
   var time = +new Date;
   //no idea what that did, let's check it out
   debugger;
   //You can now modify local variables as well
   alert(time);
})();

Pro Tip: ‘debugger’ statements cannot be disabled at runtime, so don’t put ‘debugger’ inside of a loop. Instead put it right before the loop and then manually set a breakpoint in the web inspector. That way once you’ve found out what you need inside the loop, you can disable the manual breakpoint and the rest of the iterations will continue without you having to mash F8.

Discussion on HackerNews

First let’s set some boundary conditions for this post. It is meant for early stage tech startups with limited resources embarking on their first usability testing experiment.

Yes, usability testing is important. But performing usability testing at an early stage startup is hard. Best practices from larger companies with dedicated product managers do not carry over easily. We learned this when we rolled out a structured usability testing exercise at Filepicker.io

Our goal: reduce friction in developer onboarding on the website. Here is what we learned:

#1: Startups are resource constrained. Think minimum viable process.

usability testing best practices advocate an exploratory, open ended approach. There are several awesome resources such as this one that can guide the experiment.
So when we started the experiment, we wanted to understand if developers had enough information on:
a) How to start using filepicker.io in their relevant language/platform
b) Whether the steps are specific enough to setup a simple integration
c) Whether they feel comfortable with the sample code
d) What other actionable items are required to go live with the service

But when we asked ourselves what we would do with the answers to these questions, we realized that we wouldn’t do much. Rather, we couldn’t do much.

Why?

None of the responses would help us determine where to draw the line on follow up actions. For example: how much guidance should we provide till a developer feels comfortable with the sample code? Or how many of the actionable suggestions should we implement?

While the open ended questions certainly yield a wealth of knowledge, what use are they if they can’t be implemented? Startups always have a sh*t-ton of work and, as it always feels, there are never enough resources. With limited resources to go around, all nice-to-have or would-be-great-to-have tasks seem like luxuries and the focus always remains on resource maximization to grow the company as fast as possible.

Therefore, the better approach was to limit the scope the experiment to prove or disprove some specific unit of measurement for a specific customer persona. Thus, we redefined the learning objective as:

“For customer persona X, it’s not possible go through the entire onboarding flow without reaching out to support@”

This allowed us to quantify and prioritize the feedback that we received from the usability testing. Initial usability testing (we need to do this for a statistically significant sample) proved that developers could finish the onboarding flow for a simple use case without reaching support (phew!). This meant that we WOULD NOT have to prioritize improving the website right away. The feedback we got from the exercise has been added to our icebox as nice-to-have rather than a must-have.

#2: Take responsibility for the entire user experience including third party products

Sometimes the problem in the onboarding flow might not lie in your product but in the handoffs occurring between your product and other third party products.

In our case configuring the AWS S3 settings is a critical step in the developer onboarding flow. When we reviewed the recording from the Silverbackapp we realized that developers were getting lost in setting the IAM policies. While we provide links in our developer portal to the AWS support page on this topic, it was obviously insufficient. Though they eventually figured it out, there was quite a bit of toggling between screens to understand what needed to be done.

It was clear to us that if we wanted to provide as frictionless as an experience as possible to the developer, then we had to take ownership of that experience as well. So we made a screenshare of how to configure the IAM permissions in S3.

In conclusion, think minimum viable process for user testing. If you are a startup, be wary of adopting best practices designed for large companies. Open ended usability testing may not be the most optimal thing. If your onboarding flow involves third party products then watch out for friction in the points of handoffs.

One of our primary goals at Filepicker.io is to create a best in class developer experience, guided by tests like this one step at a time. Try us out and tell us how we’re doing.

-Chintan & Anand

Follow the discussion on HN

[Edit]-Per Chris Smeder’s comment on HN, user testing has been changed to usability testing throughout the article.

Unfortunately, I couldn’t change the title as it would break the url which has been reblogged and distributed.

Very recently, without many people realizing it, there’s been a major shift in the way that software companies treat cloud storage services like Dropbox, Box, Google Drive etc. Online storage is starting to become a primary hard drive for users rather than a secondary. We’ve been seeing it in the rapid pace of our growth as well as through moves by others in the space, such as the Dropbox chooser and Gmail adding attachments from Google.

Originally, people only stored files online as backups. Then Box and later Dropbox opened up the collaboration use case, storing files online so they could be shared between two people. Now, people on an appreciable scale are starting to use the files they have in online storage as the primary version, particularly with photos. In more and more cases, the content that people want to work with is not sitting on their local hard drive, it’s online, synced up there by their mobile device or shared from a friend.

This is why we created Filepicker.io, to help developers deal with this migration of the primary content to the cloud, and with products like the Dropbox chooser and Gmail-Google Drive integration surfacing, it’s clear that the industry is moving forward, that consumers will soon expect their applications to work with directly cloud storage. Of course we believe that applications should integrate with all the cloud storage services not just one, but there are other interests at stake and so getting all applications to work with all sources of content will take time. For now, we’ll keep encouraging applications like Cloudy that add in multi-platform support.

Users are starting to treat online storage as primary sources, and as the applications they use start working with that content directly, it’s a major step forward in the notion of the web as a platform. As we at Filepicker.io and elsewhere push this notion of interoperability forward, we’ll see a web where from any device, a user can log in to their accounts, view, store, edit, and share their content, all online, without ever needing to download or upload.

We started this company with the belief that as more content went online, there needed to be a better way for applications to work with this online data. And this change is happening now, with some customers now having over 70% of uploads starting from the cloud, up from 20% several months ago. To us, the shift towards people using online storage as their primary drive is very exciting, and we’re thrilled to have played a role in pushing it forward. The signs of this paradigm shift are just starting to show, and it’s only the beginning.

Discussion on Hacker News