Changes to android2cloud

[Paddy Foran]

Hey everyone,

I'd like to start this (lengthy) email by reminding you of my request
that things discussed in this group stay confidential within this
group. This email doubly so, because a lot of controversial things are
in the works.

By now, I'm sure some (most?) of you have seen my videos (http://
www.youtube.com/watch?v=FNfTBjOKIKE and http://www.youtube.com/watch?v=2fKI85mQ5mM)
of the beta, currently dubbed version 1.0. I wanted to take some time
and fill you in on my plans and ideas, and have a chance for feedback.

First, I apologise for not releasing a beta yet. I'm sure many of you
are eager to try this out with me. Part of the limitation of the
Channel API is that each client needs a channel token, and these
tokens expire after two hours. The API is still in its infancy really,
so Google has no recommendations for how to check the validity of a
token and renew it if it's not valid yet. I'm told that information is
coming, so I'm kind of just sitting tight and waiting on Google to get
that info to me, and will be releasing it to you as soon as I have a
client that does not need to be reloaded every two hours. Sorry for
the delays.

Second, if the videos didn't clue you in, I'm taking android2cloud
beyond a simple Android to Browser link sharer. My inspiration comes
partly from Andrew Banchich, a good friend of mine and a great font of
ideas, and partly from Avatar. For those of you that have seen Avatar,
the tablet-esque displays they have (picture:
http://www.technovelgy.com/graphics/content10/avatar-screen.jpg) is
what I'm drawing inspiration from. The people in Avatar can be looking
at something on that, and just swipe it from one device to another.
Sharing the contents of our screens, sharing our information, should
be that easy. Just swipe from where it is to where you want it. Where
android2cloud version 0 was focused on people (links were sent to
accounts) android2cloud version 1 is focused on devices (links are
sent to device objects, which are owned by accounts).

This next release of android2cloud has been dubbed M.I.S.S.: Make It
Social, Stupid. And yes, android2cloud is becoming social. Devices are
designated by yourus...@yourdomain.com/Device strings, like Jabber,
which makes it simple to send a link from one account to another. As
the videos show, comments are possible, and appear in a notification.
I have a lot of ideas about this. I'll outline them below.

1. I'd like to make it simple to share links with your friends. Stupid
simple. I'm envisioning a button on the Android app to import your
contacts, and when you select a contact, you get a drop-down of the
devices they have registered on the server you're using. If they
aren't registered on that server, you get a notification, asking if
you want the server to email the link to them, instead. I have a
feeling that as people email links to their friends, the user base
will explode. Which is awesome, but will probably lead to more server
issues. Which I'll get to in a minute.

2. I'd like to make it simple to share links with a lot of people. I'm
working on "Channels" right now, which would be designated by
something like yourus...@yourdomain.com#Channel, or $Channel, or
even |Channel. I haven't entirely decided yet. But think of a channel
as akin to a Twitter user feed: people choose to follow a channel, and
then you can send updates to your channel. Those updates open in your
followers' browsers. So, for example, I have foran...@gmail.com|
android2cloud, and every time I need to announce something, I send an
update there. Everyone who is opted in gets the update.

3. I'd like to end the dependence on Android to send links. The Chrome
extension will almost certainly be able to send links as well at
launch, so your friends don't need Android to use this service. And I
have started investigating a Firefox extension. I hope to be able to
launch with Chrome and Firefox support.

4. I'm imagining the permissions for this as pretty simple. By
default, links sent to you by other people result in a notification
with the person's name, the link they're sending, and five choices:
always open links from this person, open this link, ignore this link,
block this person, and report for spam. I also can see setting
defaults for groups, e.g. "always open links from people in my Friends
list in GMail" or "Block everyone in my Family list in GMail".

5. I'd like to let people escape the social graph being created here.
Channels should be followable from Twitter. Things like that.

6. I'd like to let people set settings on whether new tabs are opened
in the foreground (interrupting what you're looking at) or background
(waiting for you to look at them).

This is a clearly a huge departure from where we are right now. It's
introducing a whole new paradigm for content-consumption: push,
instead of pull. We're used to seeing content given to us in link
form, and we make a decision as to whether we want to see it or not.
It will be interesting to see how people react to the option to have
content literally pushed in front of us, with no decision to see it
necessary. Obviously, as with any paradigm shift, permissions are
going to be an important factor in this, and I need to get them right
the first time. I'll really need your guys' help testing and refining
the permissions and social part of this, and have some ideas on how to
make it effective.

Now, as you can probably tell, this is turning into much more of a
service, and will clearly be a lot more CPU-intensive than the current
offering. Well, the backend stuff, at least. I'm anticipating a huge
benefit from the lack of polling (the browser loading the server every
15 seconds to look for a new link), but this model I have laid out
above will not be sustainable forever on a free quota. Which means
I'll either have to find a company with deep pockets to fund this,
will have to start charging for it, or will have to think of a way to
monetize this in the future. I'm dead-set against charging for this,
or even for features. I wrote this for fun and because I wanted to use
it, and asking for people to pay me for that is a repugnant idea. As I
said, though, this is a paradigm shift from content pull to content
push. And I think advertisers would be very interested in that shift.

Before everyone panics, let me reaffirm my dedication to my users'
experience. I absolutely refuse to degrade their experience with ads
or drive people away with ads. As I wrote in April (http://
www.paddyforan.com/2010/04/i-support-twitter-ads-and-so-should-you.html),
the advertising industry is built on bring people and products they
would like together. It is, when done right, a service. The only
problem is that advertising today sucks, and advertisers are
unscrupulous about how they get the page impressions and sales, as
long as they get them. If I can figure out a way for true advertising,
bringing a user and a product they will probably like, together in a
monetizable way, I'll consider enabling that in the future, to try and
support the service. Such a solution would almost certainly be
organic, meaning it would be subject to the same permission system the
rest of the system is subject to, and would definitely be opt-out. I
mean it when I say that users come first, monetization comes second.
I'd rather shut the main server down and require people to run their
own than bastardize the system by pushing content they don't want to
see in front of their face.

In the event that I enable advertising, I'll be doing a few things.
First, I'll be doing my homework, so I can strike deals with the
advertisers that put me in control of the ecosystem, and make sure no
advertisers are abusing the system. I would be using a customized ad
solution, not a pre-built one like AdWords. Second, I'll probably be
incorporating. This will be to protect me from legal ramifications of
such a large product (I'd like to not lose everything if someone
decides to sue me, thanks) and because I'd have to consider hiring
help at that point. Such help would come from within the community,
and would be used in positions like Community Support and Advertiser
Relations. I love building this project, and love interacting with
you, and promise to do my best to keep a close connection to all of
you in the future, but I also am the main developer for this project
at this point. And I have a lot of ideas. I'd like to spend more of my
time implementing those ideas, and less of my time helping people set
up their account.

In the event that I incorporate, I want to reassure you all that this
project will always be 100% open source. The android2cloud server will
never use technology that is not released or in the process of being
released to the community. I will never have any proprietary claims to
this technology. That is my promise to all of you.

My final note (then I'll end this novel of an email) is that the
moniker "android2cloud" doesn't really make sense for the new product.
What would you all think about re-branding for the new launch? Does
anyone have name suggestions?

I just wanted to share my thoughts, ideas, and plans, and see what all
of you thought. Thanks for your support, your beta testing, and your
ideas. You all are wonderful people, and I really appreciate having
you as users. I hope I live up to your expectations for me, and never
disappoint you.

Bring on the feedback!

Thanks everyone,
Paddy Foran

[Eric Mill]

I love the energy behind this plan, and I like the vision of broadening android2cloud into something that goes beyond "phone to Chrome" or "phone to web browser".  And your preview videos are exciting stuff - the Channel API makes things so fast that it literally expands the imagination.

But I would strongly encourage you to plan this out incrementally - frequent releases that change parts of it out one at a time, whenever possible. For example, before adding social features, put out a stable release that swaps out the current server-client communication for the Channel API, and pretty much nothing else. Then, a release that builds on that and adds comments. Then, a release that builds on that and adds a UI for specifying multiple devices. Then the permissions infrastructure. Then the spam filtering. Then a revamp of the UI.  Etc. The order isn't important.

This ensures that you have something stable at every step of the way, and that you're getting feedback and testing from the broader user community at every step. This beta list you have here will be helpful, but nowhere near as helpful as your releases, especially when you start getting as ambitious as you're about to.

Plus, the Market rewards frequent releasers by promoting your app to the top of the Just In category - bonus!

I say all this because I'm getting the vibe from this post that you're so excited about all of the social and device possibilities that you want to tackle everything all at once, and get lots of feedback from your smaller committed group of beta testers along the way until voila - 1.0, it's stable and ready for the world.  This rarely goes well, and is how a lot of ambitious projects have ended up fading away before their release. It's important to just get it out there.

And if I'm wrong on this interpretation, then you can just take this as good, if unnecessary advice. :)  Either way, I'm enthusiastic about the project, your goals, and look forward to helping.

-- Eric

[Paddy Foran]

Eric,

Thanks for the reply! Sorry it took me so long to get back to you-- I've been swamped.

I was sort of planning on releasing incrementally-- Channels, for example, would probably come a few releases down the line, after things settle a little and the dust clears. I do appreciate the advice, though, and think you're right-- I'll end up breaking the releases even smaller. At this point, though, I'd like to get a pretty solid idea of what will *eventually* make its way into the service, or what I'd like to be able to include, because the App Engine datastore isn't kind about updating the database fields when they already have content in them. So I'm trying to get the server capable of all this good stuff before piping more information in, so I don't have to spend an unwarranted amount of time trying to convert data over to new schemas when I realise links need to have a Channel property, or something.

I think, based on the way the server needs to be set up for this to work, the most sensible rollout strategy would be something like:

-- release the Channel API, with a new Android app that lets you choose which of your devices to send to. The Channel API needs specific identifiers for each client, so I am pretty much forced to do these together.

-- add the ability to send links to friends, and the permissions infrastructure for dealing with them, when the dust clears.

-- add comments when the dust clears.

-- add channels.

Something like that, I think, would pretty much isolate the features as much as it makes sense to (users will complain if they don't have permissions to control how their friends send them links, and the permissions won't make sense without the ability to share links with friends, etc.). I'd love to hear your thoughts on it, however.

And, of course, I'd love to hear any other ideas for the service-- again, my goal is to update the database schemas once, not a dozen times, so if you have a big idea, now is the time to voice it-- even if it won't get seen for a few months. :)

Thanks,
Paddy Foran

[Eric Mill]

I can definitely empathize on working with App Engine's database - I did a small Wave bot in the summer of aught 9 that stored a few thousand rows about bills in Congress, and any updates to the data or the schema were a colossal PITA to perform. I had to write my own Ruby scripts to manage running the Python scripts that App Engine ships with to manage updating the database remotely.  Not fun. :(

Looking forward to testing out the Channel API release! Also, when things calm down a bit for me, I still intend on chipping in some UX work on the Android app. :)

-- Eric