Zipiko has on a number of occassions been compared to Dopplr. Take this Techruch entry for example "Zipipop
(from Finland) is a start-up that is developing Zipiko, a mobile service for sorting your social life on the go, as in, broadcast where you’ll be at a certain time in the day. Think Dopplr, but on a much more granular level perhaps."And according to Dopplr's latest press release it “is leading the way in intention sharing services online." This is interesting to Zipipop, since we have previously blogged about Dopplr being an early example of what we are calling intention broadcasting systems (IBS). However, Dopplr is not a fully-formed IBS, since it lacks the fundamental 'coordination' phase; which means that you can easily end up getting too much direct and sometimes intrusive calls/messages. A complete IBS should be handling and coordinating the meetups more passively – something that Zipiko does well.
However, the Zipiko system is not able to let you know which city your buddies are going to be in until they have already arrived and shared an event. So it dawned on us that there is a good potential here for cooperation – especially since we are both in the business of intention sharing and we also happen to we live in the same neck of the woods.
So in the spirt of Zipiop's first official slogan 'Sharing Life', this is how it could work:
Dopplr allows people to know when they will be in the same city and then Zipiko allows them to easily arrange their get-togethers – kind of a Blogger/Twitter, macro/micro relationship.
@Dopplr posse – Let's meetup at somewhere, sometime soon: As Bogie says, "This could be the beginning of a beautiful relationship."
1 comment:
Probably a good idea. On a simpler level it would be good if Zipiko could know when I'm out of town as it then would not need to send me invites to go for a beer in my home town pub.
So how could Zipiko be aware of the high-level whereabouts of a user, if at
all possible with an eye on the nearby future (the scope of Zipiko, perhaps one week?):
i) let the user explicitly tell. Works but is not nice for the user
ii) infer from a calendar of the user. Could be Google, Dopplr, or all of these
iii) infer from location info, from the operator or through a phone app. This obviously only provides "current" location, but is non-intrusive. Zipiko would only need "town-level" granularity which is fairly easy to get.
I think I'd start with ii) as it is easiest and has some other benefits.
And, ooh, now that I mentioned calendars: I'd really love to see Zipiko make an entry in my (let's say Google) calendar when I create or accept an invitation.
Post a Comment