Why is there so much talk about hypotheses and market validation in the article when the product is a straight up clone of WeTransfer almost down to the name?
Right, this is a really good question. Dropbox Transfer achieves the same purpose as WeTransfer with a few differentiators. Unpacking this a bit, there are two parts here:
1) For a company with an established sharing model (shared folder, live-updating links), a departure or addition to this needs to be thoughtfully orchestrated. Moving to snapshotting content, gathering content inside and outside your Dropbox, and enforcing expiration in this tool is a very different paradigm.
2) However, specifically because we are also a storage provider, we can provide a much faster sending experience for them as we can remove the upload step, which is especially important for folks sending really large files. We have a large user base storing their content in Dropbox, this is a net new added value/functionality for them.
Even if the internal discussions were "other services do this and we want a piece of that pie", no company is going to come out in a product launch announcement and directly say "another service is doing this and we want a piece of that pie".
And in this case, I would still hope they did do market validation internally, even if it is just a copy of wetransfer. Just because some other company is doing something doesn't automatically mean it's a good fit for your company to do it, too.
As for the design, it's pretty hard to say that "a generic file selection panel in the middle of a page and a Sign Up button at the top right of the page where it typically is on most sites" is a "straight up clone". The color schemes are similar, but that's just because the main color branding of both companies happens to be light blue.
Same issue on Windows. If you are adding new context items automatically, please have decency to add option to remove them, without hacking the registry. Also, please do not add it back in later update, which happen quite often.
Great work on this. I had to send 100GB files last year (1TB in total) and it was extremely difficult to send them as-is. Most clients that upload data choked while attempting it. Had to break the files up into smaller ones using a compression tool. It actually increased the file size overall but the transfer could then be facilitated.
Hope to see you guys add a feature like DocSend next. It’s like a missing puzzle piece from a utility perspective. I have no idea who downloads a shared file once a url is generated. Would be nice to request emails and get alerts when it’s downloaded.
If you use 7zip on Windows or just split/cat on macOS/Linux, you can split without compressing or archiving, saving you unnecessary CPU cycles (and space).
Hi! Sending groups of files was definitely one of the focus areas here so hope Transfer can be helpful in this role.
Re: Tracking content, we actually do provide this in Transfer. If you specify a set of email recipients, rather than copying a shared link, we provide a few tracking features for you.
1) Record who has viewed or downloaded your content.
2) Remind your recipient if the content you sent is about to expire.
3) (Optionally) notify you to let you know when your recipient has downloaded your content.
What was the most technically challenging part of the project for you? And do you do any tricks for handling failures during very large downloads or uploads (Eg ranges)
The most technically challenging part was probably wiring the storage & sharing side up to not behave like a traditional Dropbox shared folder or shared link (e.g. not take up storage quota or sync down to your machine). There were certainly a long tail of internal reliability work to get that operating smoothly (there are many internal services to work with here).
In terms of tricks at handling failures:
The first (and probably most important) thing is finding the failures. Bug bashing sessions and also just reading failure logs can help catch the trickier transient problems our integration or unit tests do not catch.
In terms of mitigating them, retries and correct error handlers in code are essential (e.g. Promise.catch case should not be ignored!). Retries on the client side are made a bit easier as we chunk uploads into 4mb blocks so any upload errors of actual content can be retried piecemeal.
1) Thanks for your hard work advocating for us and for that interesting writeup, and
2) This was never a problem I needed solved until Dropbox killed the Public folder four years ago. It took exactly two clicks to create a direct link I could send to anyone, and it just worked.
For those who don't know: compare the visual design of https://www.dropbox.com/transfer with the design of https://wetransfer.com/. Design and location of key elements are super similar.