That's an awkward one. Much as it would be nice to be on other platforms, I really want to build an app that I want to use daily and has a great user experience. I wouldn't be so keen on building for a platform I don't use. The JSON feed format is pretty basic, so maybe someone else could provide a Linux client with similar features.
Wouldn't alternative implementations be at odds with your stated monetization plan? I mean, it'd make sense if you were running the platform, but isn't this just a bunch of JSON files in a shared Dropbox folder?
It's a great idea technically, but I'm not sure whether you can sell a social networking app. Social networks are valuable in proportion to the number of users, and pay-for-access adds a huge barrier to growth.
They might be better off running some unobtrusive ads.
Fascinating. Dropbox is e first really popular "filesystem in the cloud" so it stands to reason that we are going to start to see services built on top of it. Rally, it is a piece of the old "everyone will have a server" dream. Except, instead of having to define as new protocol for evry service, you just use JSON over http. There is a lot of potential here, much can be made of a publicly available everywhere filesystme.
Except, instead of having to define as new protocol for evry service, you just use JSON over http.
Why do people keep saying things like this? These are protocols, but they are at different levels. HTTP is the transport protocol, JSON is the serialization protocol, but you'd still need to define a protocol to communicate the content. What will the fields be named? How do you handle missing fields, which are the required ones? Will all data sources that list photos agree to naming the fields the same? And what about field metadata, and metadata for the field metadata? Maybe that can be avoided with namespacing. Now we have something as crappy as XML.
The frustration of XML can be divided into two parts:
1. The frustrating infrastructure build around it, such as SOAP which is anything but simple
2. The verbosity of the protocol itself which frustrates human readability which supposedly is a key feature of XML
If we use JSON and avoid the infrastructure mistakes of XML (e.g. requiring huge amounts of boilerplate for RPC calls), then I think the native readability of JSON makes it a far better choice for serialization protocol than XML.
Yeah, that's great, but my point was that HTTP+JSON solves the easiest part, not the part that actually needs to be done: creating an agreed upon format for the content being serialized (via JSON) and transported (via HTTP). When that was attempted with XML, it ended up with multiple query methods, multiple schemas, new and obscure transport wrappers (SOAP over SMTP, for example).
Maybe we can avoid a Second System Effect now going forward... if XML was the Second System.
"Rally, it is a piece of the old "everyone will have a server" dream. Except, instead of having to define as new protocol for evry service, you just use JSON over http."
The key point isn't HTTP, it's synchronization. Rsync, git, and content-addressable storage in general are going to be the next big thing in the web.
One of the exciting things about the "everyone has a server" idea (http://wiki.debian.org/FreedomBox are working on it) is actually the move away from shitty one-way NATed HTTP and onto IPv6 and a full spectrum of two-way protocols.
The other exciting thing is the wider deployment of encrypted traffic (although that's more the fault of Firesheep), and public-key cryptography (how else are you going to build distributed social apps?).
"much can be made of a publicly available everywhere filesystme."
Amazing! Rian Hunter from Dropbox mentioned his vision about apps in this style in his talk at PyCon, that is very interesting in general: http://pycon.blip.tv/file/4878722/
1. Once someone has replied to your message you can't delete the conversation. If you could perhaps implement a "request delete" or something, so that if everyone agrees you can delete a conversation tree? Right now my "feed" is cluttered with lots of test convos. Another solution might be having a separate .json file for every user?
2. It wasn't obvious to me how you shared files. The "Set hotkey" option in the preferences should maybe be renamed to "Set file share hotkey" or something, at least explain a bit better without having to go the FAQ.
Other than that, looks good for a beta! I got a really strong "why didn't I think of that" feeling when I first tried it :)
If you were the last person to reply in a conversation you can delete your own reply by holding down the option key. The reply button will then change to a delete button. There is still currently no way to delete an entire conversation though.
I was possibly thinking of adding the ability to archive items you've seen already so they don't show again.
Regarding point 2 - thanks, good thinking. I will definitely need to make this clearer as many are still confused as to how to actually share things. Most try and drag files into the message text field or onto the menu item which is not yet supported.
> I was possibly thinking of adding the ability to archive items you've seen already so they don't show again.
That would obviously be the best solution. Check for duplicates in the archive.json and the normal .json and hide them or something. This would be great!
> Regarding point 2 - thanks, good thinking. I will definitely need to make this clearer as many are still confused as to how to actually share things. Most try and drag files into the message text field or onto the menu item which is not yet supported.
That was what I tried first as well, so it seems like it would be a smart thing to implement UX-wise :)
To add to the bug report thread, there is no way to get out of the very first dialogue the app presents (choose shared folder to use). If I don't select anything, I can't close the app in any way except for using Activity Monitor.
Looks like a neat concept. It seems dropbox is fast becoming a platform. The other day, I was suggesting someone that they use quickbooks over dropbox for using it on multiple locations. I figured it does not work very easily, but the whole idea of using dropbox as a platform was kind of interesting.
We are starting to use it to synchronize a photo identification database for wildlife conservation workers in Kenya: http://code.google.com/p/stripespotter
It becomes a lot easier if you design your application with Dropbox integration in mind (use plain text where possible, etc.)
Dropbox is version control without commit messages or merging. That was fine before people started using it to collaborate, but if its going to be a collaborative platform its going to have to grow those features. Which would be wonderful.
Agreed. It would be much nicer if you could just put your friends email in and it would handle setting up a shared folder and inviting your friend automatically. I have yet to see whether the Dropbox API will support this.
Unless you make it run everywhere Dropbox runs this is gonna be "The Dropbox + Mac powered social network".
I'd like to try it and give some more constructive feedback but I'm running Ubuntu.