That explains why nearly every Filepicker blog post makes it to the front page! :)
Filepicker.io (YC S12) lets content flow without worrying about bandwidth
11–20 of 24 posts
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#12When I first heard of filepicker.io I thought it was a stupid idea. File uploads aren't hard to do, after all, so why pay a third party service for it? However, used Filepicker at the NY eCommerce Hackathon recently because we needed to implement file uploads in a hurry and was very impressed with it.
Took about 5 minutes to get image uploads enabled in our web app, including allowing people to take pictures directly from a webcam. No screwing around with file POSTs, sanitizing, storage, CDNs etc.
Looking forward to using it in a real project.
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#13Earlier quoted context omitted.
I would give them a break. Rather than just criticize them maybe provide useful feedback about content they could send you or why you think the emails weren't useful. If you don't like the emails just hit reply and tell them why. I'm sure they'd happily adjust what they are sending out based on good feedback. Getting this stuff right is really hard for an early startup. You don't send enough email and you end up forg…
That's the startup's problem and not their users. It's too much work to reply to every email you get which you wish you didn't. I realize it's hard but the onus is on the startup to get this right. In the process they'll piss off some users but that's the process.
True, but it wasn't too much work to find a HN thread about it and complain there.
Either be constructive or don't say anything. Both are good feedback for the startup. Being mean doesn't help anyone - the startup or the user.
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#14Earlier quoted context omitted.
That's the startup's problem and not their users. It's too much work to reply to every email you get which you wish you didn't. I realize it's hard but the onus is on the startup to get this right. In the process they'll piss off some users but that's the process.
True, but it wasn't too much work to find a HN thread about it and complain there. Either be constructive or don't say anything. Both are good feedback for the startup. Being mean doesn't help anyone - the startup or the user.
While combataircraft's tone isn't the nicest, he's voicing exactly what he's unhappy about, giving the Filepicker.io guys the information they need to improve in the future.
Could it have been put in a friendlier tone? Sure, but I'd argue that his feedback is actually constructive.
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#15Getting customer data into your system is harder than it looks. Flash uploaders are pretty crappy, but you need them for IE users and direct to S3. Flash is broken for mobile, of course, as is the whole 'upload from computer' concept. Box, DropBox, Google Drive, flickr, and everything else is extremely popular, so if you start implementing all those yourself it adds significant development time and code to maintain. Filepicker has been a huge win for us at PlanGrid.
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#16Getting customer data into your system is harder than it looks. Flash uploaders are pretty crappy, but you need them for IE users and direct to S3. Flash is broken for mobile, of course, as is the whole 'upload from computer' concept. Box, DropBox, Google Drive, flickr, and everything else is extremely popular, so if you start implementing all those yourself it adds significant development time and code to maintain.…
Just FYI, for xhr to S3 you can set up a proxy which fakes the CORS headers. You might have already been aware of that.
Filepicker looks neat. I wish it had been around when we were building our service.
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#17I like the concept of filepicker.io: a standardized widget for providing files that handles local files, remote URLs, and services people use. However, every time I read the phrase "by inserting a few lines into their source code", I think 'yeah, and one of those is a script tag pointing at a third-party server'. And sure enough, looking at the documentation, I see exactly that.
I really wish web services would start providing instructions for self-hosting all scripts.
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#18I like the concept of filepicker.io: a standardized widget for providing files that handles local files, remote URLs, and services people use. However, every time I read the phrase "by inserting a few lines into their source code", I think 'yeah, and one of those is a script tag pointing at a third-party server'. And sure enough, looking at the documentation, I see exactly that. I really wish web services would start…
If you self-hosted the script then it wouldn't be able to communicate with their servers, I think (someone can correct me).
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#19When I first heard of filepicker.io I thought it was a stupid idea. File uploads aren't hard to do, after all, so why pay a third party service for it? However, used Filepicker at the NY eCommerce Hackathon recently because we needed to implement file uploads in a hurry and was very impressed with it. Took about 5 minutes to get image uploads enabled in our web app, including allowing people to take pictures directly…
> ... in a hurry
But that's exactly it - if you are in a hurry, you'd be more willing to create a dependency on 3rd party and take on the risks that you can avoid otherwise. I'm sure there is a market for filepicker-like webapp component services, I just suspect that their user base is going to be highly transient (edit - or hard to monetize on).
Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth
#20I like the concept of filepicker.io: a standardized widget for providing files that handles local files, remote URLs, and services people use. However, every time I read the phrase "by inserting a few lines into their source code", I think 'yeah, and one of those is a script tag pointing at a third-party server'. And sure enough, looking at the documentation, I see exactly that. I really wish web services would start…
We currently try to push people towards pointing the script tag to us so that we can more rapidly iterate on the product.