[Design] IDC: 100 million cameraphones to be sold next year

[Hamish Harvey]

Selva,

I get the impression you perceived what I said as criticising your ideas. They 
triggered additional thoughts, in some cases I disagreed about the approach 
you suggested (implied or explicit), in others I was simply voicing 
additional thoughts triggered by your post.

I've added the list back, since this does flesh out some of the issues 
discussed.

On Wednesday 15 Oct 2003 12:13 am, you wrote:

> > Is it not the case with Palm based smartphones, as with older Palm based
> > organisers, that sync with Outlook goes _through_ the Palm desktop? So it
> > isn't a matter of syncing with the Desktop _or_ with Outlook, but of
> > syncing with both?
>
> I think you may be right here.  However, I don't think this is a strict
> rule because Linux based organizers such as that by oeone.com also allow

You're absolutely right; any piece of software _can_ be written to sync with 
any device (assuming sufficient information about the protocol is available, 
which in many/most cases it is).

The point is that users increasingly have mroe than one device (eg, phone, 
PDA, for those of us who don't have a smartphone :) which needs syncing with 
Chandler and with other devices. From this point of view my suggestion of 
syncing through Palm Desktop is actually broken too, what is needed is a 
Windows equivalent of multisync (assuming that works, and works effectively, 
I haven't used it). These sync frameworks should contain the n-way conflict 
resolution logic required in this situation, and Chandler just becomes one of 
the possible "devices" to sync. This has the advantage of allowing a new 
Chandler install to be synced with any other device which the framework knows 
about (could include Outlook), and allows people to test the waters with 
Chandler without committing, which is probably important for uptake. It also 
provides a clear exit path, which would make people less resistant to 
adopting Chandler ("If I want to dump it, I can just sync with package X and 
carry on working").

> for synching with Palm compatible handhelds.  As well, Sun's Solaris
> desktop version ships with Palm compatibility as well.  Hence it would
> appear that one is not confined to going thru Palm Desktop since Palm
> Desktop doesn't exist for Linux and Solaris.  Furthermore, I 'm not sure
> but I don't think Apple's iSync works thru Palm Desktop.  I may be wrong in
> the latter case though.

I'm not familiar with it, but the name suggests that it is essentially doing 
the same job as Palm Desktop but in a more general way. I'd guess that iSync 
is precisely the n-way sync framework that you would want to link with on OS/
X. This is interesting, because it begins to imply a host-OS based 
multiplicity of sync plugins, rather than a device based multiplicity. On the 
whole OSs multiply at a slower rate than devices, so perhaps this is a good 
thing. Just one would be ideal. If OSAF in the end felt in necessary to write 
their own sync framework so be it, but there are a number of open source 
efforts, so if one of these could be adopted it would be more sensible.

> > And while this is a feature I very much want in a PIM, it ought to be
> > possible to postpone thinking about it until the core functionality is
> > done.
>
> Sorry, I didn't mean to sound like I was demanding too much too fast but
> rather just to convey some of the needs which lay users may like to see
> down the road in the future.

I didn't need to make that comment to be fair, the OSAF folks seem quite 
capable of deprioritising features back into future versions where necessary.

> > Likewise, linking up with a sync framework (eg by providing a Chandler
> > plugin for multisync http://multisync.sourceforge.net/) is the way to go,
> > not trying to support every nuance of every smartphone and organiser that
> > hits the market.
>
> I'm not familiar with multisync Hamish.  If it gets the job done then
> that's great.  So long as lay users don't have to fiddle around with port

http://multisync.sourceforge.net/
Unixy platforms only, but quite a flexible architecture. I haven't used it; at 
the moment it doesn't support the Palm (maybe it's time I got a Zaurus). 
There is a SyncML plugin for it around, though I can't see mention of it on 
the mutisync pages; in theory SyncML should allow me to sync my Nokia 7600 
with it if I could make my 7600 talk to my Linux laptop.

> settings and the like as much as possible, then it should go over well. I'm

I fear that the archticture of Linux's dealing with USB ports and whatnot 
might interfere with attempts to make this really easy (an impediment to the 
adoption of Linux on the desktop hoped for in some quarters).

> not sure what technology Apple's iSync uses but it seems to work well with
> Palm devices without much user interference so perhaps this is something to
> study further.

Indeed, this is what Apple have traditionally been quite good at. They have an 
advantage of course in achieving this ease of use in controlling both the 
hardware (of the PC, not the handheld, of course) and the software.

> > The Chandler data model should make support for storing and cataloguing
> > photos straightforward I would hope.
>
> Again, when something is straightforward for a developer, it doesn't mean
> it's the same to lay users.  For most non-tech users, pre-configured suites
> of applications that work well together out of the box tend to be more
> popular and practically useful.

Understood. My point was just that if the data model is right, then even if 
this feature isn't in the first version it should be straightforward for a 
developer -- OSAF or otherwise -- to add as a package. I'd rather see a 
version with traditional PIM pieces of functionality out and debugged before 
OSAF spend too much time on other things. On the other hand, It'd make sense 
for them to keep some trial extension packages up to date with the core of 
Chandler to test the extension mechanisms.

I'd *much* rather see support for handling RSS feeds before photo management. 
There are some ease of use issues to be worked out with RSS before it gets 
really big, but I strongly believe it will. On the other hand I do have a 
camera phone (and I do use it as a camera, and make no use of the connection 
between camera and phone) and would welcome a competent tool for managing my 
photos, preferably with information about who was in them and things like 
that.

> > I'd sooner see a photo attached to an incoming email recognised to be a
> > photo and indexed as such.
>
> It's one thing to index a photo for future search purposes but I wouldn't
> want all photos that come attached with emails automatically filed into my
> family album - especially those from XXX spammers.  What I was refering to

Heh, that's a good point. Hadn't thought of it.

> If I see a photo attached to an email, I should be able
>
> > to do exactly the same things with it as I can with a photo in a photo
> > album (including copy or move it to another album). No modes: a photo is
> > a photo is a photo.
>
> Again, there are many ways of getting from point A to point B in the
> digital world but it's the easiest and user-friendly ways to do it that
> become widely adopted.  Preconfigured apps that allow the user to do it

I'm not at all convinced by that. Can Outlook be decribed as user friendly? 
It's a dogs dinner.

> easily by, for example, right click contextual menus tends to make it more
> simple for lay users.

Aye, but one of the things that makes it hard for lay users is inconsistency. 
*Nothing* is intuitive until you've learned how to do it, either specifically 
or by similarity with something else that you've learned to do. This is a 
plague on all current desktop environments. The fact that we have to work in 
so many different applications is part of the problem. If a "lay" user, who 
hasn't worked out the "logic" of a computer, sees a picture, I think they 
would reasonably assume that they could do the same things with it as when 
they saw one five minutes ago in some according-to-the-computer different 
context. Thus, any picture, anywhere, should provide the same options: move/
copy to album (of which there could no doubt be several), send by X/Y/Z, and 
so on. The fact that the picture you are looking at is in an email is neither 
here nor there.

> > It would be much nicer to have a plugin for OpenOffice that let you pick
> > certain object types from Chandler as if Chandler was a file system
> > (which it is). I tend to think "get a picture for here" from a document
> > rather than "here's a picture which should be in this document" if you
> > see what I mean.
>
> By making Chandler and OpenOffice interfaced more directly with pull down
> menus and the like, I didn't mean to imply that OpenOffice photo import
> system should be restricted to Chandler.  Rather, the tight integration
> between the two apps could be supplemented with options to get a photo file
> for Writer from other sources as well.  The tight integration is simply
> something that non tech users would tend to appreciate in using the product
> in day to day life.

Indeed, no disagreement. I as taking the idea further and suggesting that it 
would be particularly powerful to be able to do something like (from 
*OpenOffice*)

Insert->image
Select "chandler" from file dialog
Browse (in familiar Chandler interface) through available photos and choose 
one.

This is a pipedream, but it's worth putting pipedreams where Google can find 
them. The lazyweb approach to development.

Cheers,
Hamish