Re: Time to communicate

[Sašo Kiselkov]

Quoting MJ Ray <mjr@phonecoop.coop>:

> Adrian Robert <arobert@cogsci.ucsd.edu> wrote:
> > Anyway, this is just to say that, groupware apps being core to a
> > large part of daily interaction in today's companies, feature sets
> > are large, and standards tend to be high. [...]
>
> Part of the problem is that these things get complicated
> fast.  The right solutions are usually simple and elegant,
> but elusive. If it were possible to bundle-ise the parts
> of GNUmail in a way that makes sense and then make TalkSoup
> and other parts fit into that (servers instead of mailboxes,
> channels and people instead of messages, chat window instead
> of view pane, perhaps), then it might just work.
>
> It could have performance benefits too. Personally, I don't use
> any IMAP services and seldom want attachments, so not having
> them loaded in memory all the time would be good. I'm not sure
> what GNUmail parts might be most difficult to include in any
> such transition to a Communicator...
>
> I think we should encourage someone wanting to take a shot at
> developing Communicator. You're right to say it's a big and
> important task, but it would be so good to see it done right
> at last, wouldn't it? GNUstep often values good over easy:
> if any group can do this, GNUsteppers can.
>
> --
> MJR/slef

Personally, I very much dislike big 'all in one' solutions and I'd opt for
splitting the software up into several apps, each of which does one thing, but
does it well. The reasons are the follows:

 - we have the Services menu (though it is being neglected for a reason to me
unknown...) and so we can have "loose" bonds between the apps while still
providing a consistent interface.

 - also, thanks to the NEXTSTEP/Mac design decision of MDI-apps not having any
special root-window, but instead all document windows floating around in the
workspace, a simple user can just click on a window (with either his/her mail,
or a window running a video-chat and the menu items automagically change to the
apropriate ones - the user doesn't even have to know that these are all separate
apps).

 - the user also often doesn't have to worry about quitting apps, simply closing
the app's document window is enough. The average app's memory footprint with no
document open is small and the OS' swapping mechanisms will take care of the
rest. (I frequently have like a dozen or so of open apps on a small 500MHz
Transmeta system with 256 megs of memory, most of the time using just a single
one and the system's performance doesn't suffer at all. And if I want to open a
document with the app I double-click it's document's icon in the workspace and
the app is brought into memory again, though this is much faster than a
cold-start.)

 - and one more note on separating a communication apps suite: look at Apple's
very popular iLife bundle. Mail, iCal, iChatAV - all separate apps, but with
well designed inter-relationships.

As for the precise choice of apps: I agree with mostly improving the present
apps which we already have, instead of trying to reinvent the wheel (though it
sure is sometimes beneficial). Next would be to design the IM-communicator app,
and making all apps use the Addresses framework.

At least, this is my opinion to the matter.

--
Saso