[Dev] Chandler and mobile needs discussion

Lisa Dusseault lisa at osafoundation.org
Wed Dec 7 14:45:49 PST 2005


I'd like to examine the PC-mobile synch solution vs. the networked 
standalone mobile client solution in terms of both (1) user numbers and 
(2) vision.  The appeal to user numbers is related to the argument that 
some people can't use Chandler unless we provide a mobile synch 
solution.

1a).  How many users MUST have PC-mobile synch from Chandler before 
they can adopt Chandler?

 From the community of people who would totally use Chandler if it only 
had a synch solution:
  - Subtract those that don't have a device, or don't bother with a 
calendar on their device.
  - Subtract those that do have a device but it's just not a killer 
feature for them -- they can use Chandler without it.
  - Subtract those that don't have the discipline to manually synch 
frequently enough for this to be useful (I'm one of these)
  - Subtract those who use a device that is not compliant with the 
standards for synching calendar data

Oops, that leaves nobody -- because the standards compliance for 
PC-mobile synch is a really bad situation and I bet if we were total 
sticklers we could rule out every device out there :)  No seriously, I 
don't want to engage in sophistry, but to make a point about how hard 
it is to target a lot of devices with one synch solution (remember the 
guy who gave a presentation about the extreme fragmentation in the 
contact info synch implementations?  I bet it's worse in calendaring).  
So what if we do a synch solution for the Nokia 6160?  Nevermind the 
fact that this phone will be obsolete by the time we are done, in the 
best case this handles only a few users.   No, it's better for Nokia to 
provide its "Phone Duplicator" software for each model they produce and 
they can work out their own kinks.

So the best we could do would be to target a few models that used 
mostly similar technology to synch, so rephrase that last "subtract" 
to:
  - Subtract those who use the wrong device -- one not supporting synch, 
or only doing proprietary synch, or just too buggy, or not the models 
we target.

How many are left?  Remember we're *starting from* the population of 
people who would otherwise adopt Chandler, and that just isn't big yet 
(when we get to Firefox-millions of users, it could be a different 
equation.)  So it's even less of not much.

1b) How many users would become able to use Chandler if their mobile 
could synch directly to a calendaring server?
Well, the question can't quite be asked the same way.  In the most 
limited sense, somebody who had a networked device that had any 
software (not just the software we provide) that could talk to their 
calendar server -- they would then be able to use Chandler without 
being cut off from their calendar when they only had their mobile 
device around.  In a broader sense, the *total users* of a networked 
mobile client could be significantly bigger, including people who can't 
or won't use Chandler for other reasons.

1c) So which approach wins in terms of gaining users?
It's not clear. I don't know if we can pick on that basis -- first we'd 
have to decide whether we were trying to get users period, or 
specifically increased users of Chandler.  Then we'd have to decide if 
the numbers made it worthwhile doing any work.  I suspect that either 
approach won't make much of a dent in the size of the user base of 
Chandler and it's a lot of work for not much difference.

2.  Which approach has the best "vision thing"?

The networked mobile client could potentially do a bunch of things a 
synch solution can't:
  - Synch anywhere there's a connection, and *never* require you to plug 
in the cradle.
  - Synchronize your spouse's and boss's calendars (CalDAV allows this 
-- synch operations don't).
  - Work with more than one data source -- your org's calendar server 
and that of your social club
  - Allow you to browse a calendar online -- even one not normally 
synched
  - Send invitations real-time.
  - Work with more than just Chandler -- work with any calendaring 
server supporting the required standard, possibly RSS and/or hCalendar 
as well as CalDAV

Even if we had a networked mobile client for one platform only 
(possibly Palm/WinCE), this could lead the way for mobile vendors and 
mobile software providers to follow.  It's much more exciting to me and 
some others.  We can't have an absolute winner on the "vision thing" 
without recourse to a dictator on the vision but I think there's a fair 
argument that the networked client is cooler even if it's not an 
immediately practical solution for everybody.

3.  So what are we doing?

Arguments aside, the current plan is NOT to work on PC-mobile synch in 
0.7, but to continue to explore a standalone networked mobile client 
project.  Mitch and I reconsidered that plan in the light of recent 
comments on the list but did not change the current plan.

My input here is intended to explain how we're thinking about it, 
comments still welcome as always. Serious suggestions about what we 
attempt should involve considerations of real chances of success and 
cost of investment :)

(FYI, I'd previously explored some of this at: 
http://wiki.osafoundation.org/bin/view/Journal/LisaDusseault20050810, 
so that's a fine place for comments or a starting point to build a 
better document on the topic)

Lisa



More information about the Dev mailing list