> Receivd - beautiful, fast filesharing for everyone
Everyone who has a Mac? Or everyone? I only see screenshots of a Mac app. There are sketches of other apps, but I'm guessing those do not exist yet.
“Real time file sharing” as a tagline seems kind of meaningless. Two reasons I don't like it: a) real-time seems overly technical, and b) real-time is implied. No one expects that there would be a delay (beyond the amount of time it takes to send the file.)
Finally, this seems like it occupies a weird grey area between dropbox and email. All the examples you give are things that I can easily do with email. If email proves to be too much of a hassle, I have to convince people to use something else, and teach them how it works. Between this and dropbox, why do I choose this?
Minor point: To look at all 4 screenshots in large-o-vision, I have to first click one, then close it, click the next, and so on. Arrows within the lightbox would be appreciated.
Also, I realize this sounds kind of harsh, but I don't mean it too—I'm just putting out there the first things that come to mind. I think there actually is room between dropbox and email, but you're going to have to work a little bit on positioning your product properly to define that space.
We're opening up Receivd to users slowly. If you'd like to get VIP access, please tell people about Receivd on Twitter and Facebook using the buttons below.
I got this message when signing up for access and I have to ask: Why would I tell people on Twitter and Facebook about this if I haven't gotten a chance to use it yet?
Do what I did: post to Facebook, and put in your message that you're testing it out and this is just a test post, not an endorsement. Then wait for the email (mine took ~30 mins).
Do this at late at night (like I did) and delete your FB post after you get the email (like I did).
Alternately, you can go the whole +hn route described below. It took longer than the FB route, but at least you're not participating in marketing of a sight-unseen web service.
I think the point is that asking a user to do this (even though they can get around it) is offensive.
"Hey spam your friends and we'll give you free stuff" is starting to get too common.
Others feel differently and are compelled to share just to get access since they like the concept enough. We did think about it quite a bit, which is why we removed the 'share to get bumped up in the queue based on your referrals' to 'just the act of telling your friends makes you important to us, and you're marked as a VIP in the db'.
Anyway, email+hn@domain.com gets you access today without having to share.
Sorry to be Debbie Downer, and a little bit off topic: when will the trend of dropping vowels from names end? Googling for "Receivd" autocorrects, and I doubt they're going to be expedient in fixing that. Domain names are now responsible for devolving English...
I need someone to hate for this. Was Flickr first?
I've been involved with several projects that did this.
The motivation wasn't to sound hip and cool, but rather to find a domain name that some squatting piece of trash wasn't asking eleventy million dollars for.
There's no shortage of good domains that the squatters haven't gotten to. Just use combinations of two words, something obvious and easy to spell from sound.
I've purchased 2 domains in the past 3 years: hackerstream and readwarp[1]. Perhaps you think they both have something wrong with them. But I contend that they're both better than del.icio.us or receivd. (Too bad that isn't all there is to a project.)
[1] In general I've been pleasantly surprised at how much of the namespace is still available. Both times I thought up a name in the shower after a few weeks of building it, and was pleasantly surprised to find my first attempt was available. Take it, done, and "find a domain name" was never even on my todo list.
I recently launched a startup which I named bfffr, playing on the word "buffer" since it ties closely to what the product does. I also chose that name because dribbble and forrst seem to be doing pretty well even with odd names like that. Admittedly I would have liked two f's, but the domain was taken. I paid close attention to how people were responding to the name. Many didn't even know how to pronounce "bfffr". I shortly changed the name to "Buffer", with the domain name bufferapp.com. It has turned out to be a very good decision. Domains may be hard to get, but there are plenty of examples out there that show we don't have to deny ourselves a good name simply because the domain name is gone (just look at all the 37signals products).
I honestly was quite surprised, but now I look back on it I realise how obviously hard to pronounce that very odd word is. It is very embarrassing to think I started with that name, but I'm glad I was receptive enough to change it and I thought it was worth sharing, as I believe many others may have similar assumptions with naming their startups. I guess that is another lesson that we always need to question our assumptions.
Domain squatters are to be blamed foremost for this. There are so many beautiful domain names with stupid ads on them as the landing page. Domain names should cost like at least a 100 bucks, wait, would even that stop them!?
Are they not also easier to trademark? You're likely to be the only person using them and made up words don't tend to have any prior usage or meaning assigned (thus avoiding the sort of battle Apple is going through with "App Store" right now).
The sarcasm wasn't evident? I thought the ellipsis and last two sentences put it away that I was tongue-in-cheek frustrated.
As for point 2: yes, English is certainly devolving. I graded papers in college -- "u" and "lol" and "tho" being present in an academic paper is a worrying trend. The writing ability of the average college-aged person that I observed personally worried me about the future of prose, and educationally we're not doing anything about it (the guilty parties also don't care). Admittedly, my sample size is small, but I can't imagine this isn't the case elsewhere.
It isn't limited to English, either. My U.S. History class in high school did a hell of a job teaching me about the plight of Asian-American immigrants at Ellis Island in the 20th century (that was our first lesson), but completely skipped the 18th and 19th centuries. The new American education.
Why should the archaic "you" or "though" with all those useless vestigial letters be considered somehow more evolved than the variants that correspond more closely to the spoken language? Likewise what's wrong with "lol"? You obviously understood what they meant, and conveying that information is exactly the purpose of language.
Languages have always changed, and grumpy old men have always complained about how those changes are destroying the language. But despite that perpetual cycle of corruption lasting for thousands of years, we are in fact not communicating by pointing and grunting.
We are in fact in many cases not communicating at all. Witness the wild misinterpretations on Hacker News, we've all experienced it. Witness the fracturing of language by region, city or neighborhood. Witness my inability to comprehend vacuous television dialog dominated by 20-somethings.
Uhm. So what is the difference here? The ability to easily share with pre-configured lists of people? The rest of what's outlined on a linked page does not strike me as something that wasn't successfully done before.
Genuine question. Consider it a lead for how to change the landing page for more clarity discussion.
We're optimizing the landing page as we go along. The difference is the ease-of-use, and the ability for non-technical folks to pick it up really quickly and get started with sharing files with the people they care about in a few minutes. Not sure if you noticed, but the current landing page is not designed with hackers in mind (we understand we're posting on HN, but technical folks are not our primary audience).
From what I can tell after signing up, it seems like it lets you essentially seed ("share" in non-hacker speak) your photos to a selected group of peers ("family/friends"). Pretty cool idea if those peers also become seeds, a la BitTorrent...
I'm sure that it exists, but could someone describe for me the main point of differentiation between Receivd and a shared folder on Dropbox?
That is, what should be compelling me to download another application to do that which I can (seemingly) accomplish with one already installed?
I'm not trying to be simply critical, but rather just pointing out that, at least from the landing page, there isn't anything necessarily motivating me to sign up. (That said, as it's on HN, I'd love to sign up, if only to provide feedback!)
We built Receivd to not just share files with our friends and family, but to have them share back photos and other stuff with us. Our parents and our friends', for example, cannot understand Dropbox's shared folders, but they're using Receivd to share photos they took with their kids. That's a big win for us.
We love Dropbox and use it everyday, but we feel that Receivd does sharing the way that most consumers understand. For example, people move stuff out of shared folders all the time, which deletes it for everybody else - just a consequence of the tech. We do know that Dropbox is killing it, and as loyal customers we're very happy for them and wish them well.
Because it has a more explicit interface (vs. Dropbox's "implicit" interface.)
That is, for what I can see with Receivd the user explicitly "opens" an app (as they're used to doing for almost anything else on their computer), which in turn clearly states "drag and drop files here to share."
With Dropbox the user needs to understand the concept of a shared folder that "magically" syncs with other computers. For many users this is an alien concept and may confuse them. I know of many people who have a Dropbox account, yet use the service exclusively through the web interface, simply because typing a URL, logging in, browsing for a file, clicking and downloading it is a concept they "get."
There's no such thing as "one size fits all" in this world---specially when it comes to user interface design.
Edit: I should clarify I do not work for Receivd, nor have any connection with the team, so I don't speak for them. This is just my assessment as a UI designer.
Minusfive's point of view tracks with years of working with non-technical customers, many of whom have a mental model suggesting that files "live in" the application as opposed to being in a folder somewhere.
I don't know how far dragging and dropping files is going to get them (many of my users could not locate a file if it bit them on the nose), but hey, it might work.
What do you mean? Just because it's in the standards doesn't mean they are treated as the same address, does it?
I don't see anywhere that myaddress@email.com and myaddress#this@email.com must send to the same mailbox. I only see that an address must "[contain] a locally interpreted string followed by the at-sign character."
Of course, this means that you can use - or ~ or # in your address but they don't have to be treated (and probably aren't) treated as the same address by most email systems.
Been using the Alpha for the past few weeks, and the product is super slick and polished for the first release.
I'm not sure why people are talking about the landing page, domain name, and other irrelevant stuff. Dropbox is really good at syncing files across systems, but not that great for sharing files quickly and effortlessly. Receivd in my opinion is trying to solve this problem.
Hmmm mac only for now. I'd be able to try this out with Linux and Windows versions. I have a mac, but it usually sends files to non-macs.
What's the advantage over Dropbox? Does your service go through a central server, or is it more p2p? Or both? Are my files encrypted on your server? Storage or bandwidth caps?
The Mac app feels unfinished — connections, files, etc. aren't draggable, reshare doesn't work (can't even select the files), but all of that is stuff you'll obviously get around to.
I'm using it now, and it's so close to being exactly what I need, with two necessary pivots that seem almost predestined to happen from your current position. The current basis of it being an inbox for files is already on the right track, and something I haven't seen attempted before, but it needs a little more verisimilitude to email:
1) The requirement to invite / induce signup / confirm "connections" needs to be ruthlessly optimized out — I should be able to just send a file to any email easily, forming a 'weak' connection. Maybe they have to do a 3 second signup to download the file, but it needs to be all in one motion. This obviously brings up a ton of issues like how to display the now 4 types of connections and unsolicited files, but it's essential to you getting traction.
2) 'sent' files need to behave like a outbox — remember that one of the biggest uses of email attachments is just sending stuff to yourself. Really you should just implement that straight up, it's the biggest use I'd have, and one I think you would find yourself as soon as you get the iOS client going. The dropbox iOS app's UI is terrible for it (pick one photo at a time and wait), plus really the filesystem metaphor is all wrong anyway! I actually want the transactional inbox feel of email here. If you don't explicitly support this I'm just going to end up using it with a computers account and an iPhone account.
Hmm, all of those things you described up top are working well for us - can you tell us what version of OSX you're running on? Also what version of Receivd are you using?
1. You can send a file to any email right now - once you invite an email, they'll be greyed out in the sidebar, then drag any files to them as you would with a confirmed user. They don't even have to signup to download the file. You can even add those folks to a list.
2. Interesting point. We'll think more about this.
Thanks a lot for your comments. Can we reach you directly somehow to figure out why you're seeing these issues?
OS 10.6.6 (10J567), Receivrd 0.7.5 (16). I expect to be able to drag a connection to a list, and drag a file from inbox/connection/list activity/received lists and the "sharing activity" lists to all other targets (including outside the app). The Re-Share button has not lit up, which did not surprise me given that I can't really get a file into a selection state. If all this is working for you, I can just try updating / rebooting.
I can send a file to any email now, but there's a lot of sharp edges. You make me click through a modal sheet wizard to intentionally setup a contact first, there should really be an email textbox / fb friend selector / etc. in your app. The worst part about the current setup is that it forces you to first send a no-context invite email minutes before sending a meaningful "x has shared y with you" email. The first kind of email really needs to only ever get sent when a user is explicitly inviting other people to share with them, which is probably not going to be the default path.
My email is in the 'about' area of my profile if you want to reach me.
I thought Notes only compresses/resizes inline graphics -- ie if you paste a screenshot into the email it will resize it -- but attachments it leaves alone. Could be wrong though.
When I go to attach an attachment, there is a box which is automatically checked as "compress". Apparently it can be set as the default with no option to change it by the user by an admin who doesn't want everyone sending large files all the time on a corporate network.
My impression was that was the equivalent of turning on gzip compression on a website.. reduced bandwidth but didn't affect what you were actually sending. Could be wrong.
I've been hurting since drop.io shut. This sounds like a good replacement.
EDIT: Functionality is quite different than drop.io and less anonymous in terms of sharing (though powerful for sharing with small groups or individuals). It would be great to get a private URL for each item shared, a la google docs.
After 5 seconds on the site, I'll share my first impressions before they fade, because I think they could be useful.
In my nominal browser view, all I see above the fold is a logo the size of an elephant, a blank field labeled "Submit", and what looks like screencaps from iTunes.
You need to label your input field better....all it is is an input field with a button that says submit. It's not very clear to people that they need to enter an email address
Have signed up! Waiting for the invite. My bro is tech averse and hence Dropbox averse. I always find it difficult to share docs with him. Hope receivd solves it for me!
Thanks for your interest, excellent comments and support! We're still giving quick access to HN users - append +hn when you signup (ex: user+hn@domain.com)
> Receivd - beautiful, fast filesharing for everyone
Everyone who has a Mac? Or everyone? I only see screenshots of a Mac app. There are sketches of other apps, but I'm guessing those do not exist yet.
“Real time file sharing” as a tagline seems kind of meaningless. Two reasons I don't like it: a) real-time seems overly technical, and b) real-time is implied. No one expects that there would be a delay (beyond the amount of time it takes to send the file.)
Finally, this seems like it occupies a weird grey area between dropbox and email. All the examples you give are things that I can easily do with email. If email proves to be too much of a hassle, I have to convince people to use something else, and teach them how it works. Between this and dropbox, why do I choose this?
Minor point: To look at all 4 screenshots in large-o-vision, I have to first click one, then close it, click the next, and so on. Arrows within the lightbox would be appreciated.
Also, I realize this sounds kind of harsh, but I don't mean it too—I'm just putting out there the first things that come to mind. I think there actually is room between dropbox and email, but you're going to have to work a little bit on positioning your product properly to define that space.