Combining iCal/Mail/Address Book
I know Address book is already in Mail, but I'd like to an Outlook-esque type application combine all three.
Frankly, It's a pain in the ass to toggle through all three when I need to do mail, calendar and perhaps whip off an envelope. Plus it takes up three icons on my dock.
Is there an advantage that I am not seeing having them be separate. Foor syncing peripheral devices, I see the advantage of separate apps. But for day in-day out use...there seems to be no rhyme or reason to keep them separate.
Perhaps 10.5 will address this, but somehow I doubt it.
And when will Mail start supporting LDAP?
Frankly, It's a pain in the ass to toggle through all three when I need to do mail, calendar and perhaps whip off an envelope. Plus it takes up three icons on my dock.
Is there an advantage that I am not seeing having them be separate. Foor syncing peripheral devices, I see the advantage of separate apps. But for day in-day out use...there seems to be no rhyme or reason to keep them separate.
Perhaps 10.5 will address this, but somehow I doubt it.
And when will Mail start supporting LDAP?
Comments
Originally posted by varian72
I know Address book is already in Mail, but I'd like to an Outlook-esque type application combine all three.
Outlook is Microsoft bloat. There is no need for Apple to emulate this anachronistic approach to application development.
Lest ye forget, Address Book is global to all MacOS X applications that want to use it. I use a lovely little envelope addressing app named Addressix which has complete access to Address Book. Address Book plug-ins allow me to map any address in the database. Another plug-in gives me the weather at any address. From where I sit, Address Book gains much by its modular nature.
Originally posted by varian72
Frankly, It's a pain in the ass to toggle through all three when I need to do mail, calendar and perhaps whip off an envelope. Plus it takes up three icons on my dock.
Oh, come on. How do you access your Outlook contact lists without toggling? Is it so much more of a pain to click Address Book's icon in the Dock than it is to click your contact list icons in Outlook?
Originally posted by varian72
Is there an advantage that I am not seeing having them be separate. Foor syncing peripheral devices, I see the advantage of separate apps. But for day in-day out use...there seems to be no rhyme or reason to keep them separate.
Perhaps, you see it now.
Originally posted by varian72
Perhaps 10.5 will address this, but somehow I doubt it.
If it ain't broke, don't fix it.... And it ain't broke.
Originally posted by varian72
And when will Mail start supporting LDAP?
Address Book supports LDAP.
Originally posted by Mr. Me
Address Book supports LDAP. [/B]
which in turn means Mail supports LDAP, since Address Book and Mail are indeed integrated.
There are, fundamentally, two different development/design/architecture/user-interface philosophies that are at play here. One I call the "Swiss Army Knife" school and the other is the "Loosely-coupled, Collaborative Component" school. Microsoft typically subscribes to the first, Apple to the latter (though not exclusively of course in either case).
To some degree this is a matter of style and preference.
I tend to prefer Apple's the "Loosely-coupled, Collaborative Component" approach. In theory, I ought to be able to replace any component with another, better component if it suits my needs better. This is predicated on open and documented APIs and data-exchange formats of course.
If you come from the Windows (Outlook) world, it may take some getting used to at first, but after some time, you might find that you actually like this "componentized" approach better. Give it a little time and see.
Originally posted by Chris Cuilla
I think Mr. Me summarizes it fairly well.
There are, fundamentally, two different development/design/architecture/user-interface philosophies that are at play here. One I call the "Swiss Army Knife" school and the other is the "Loosely-coupled, Collaborative Component" school. Microsoft typically subscribes to the first, Apple to the latter (though not exclusively of course in either case).
To some degree this is a matter of style and preference.
I tend to prefer Apple's the "Loosely-coupled, Collaborative Component" approach. In theory, I ought to be able to replace any component with another, better component if it suits my needs better. This is predicated on open and documented APIs and data-exchange formats of course.
If you come from the Windows (Outlook) world, it may take some getting used to at first, but after some time, you might find that you actually like this "componentized" approach better. Give it a little time and see.
If I may add one point.
In CC's collaborative component approach, the memory usage in smaller apps is much lower as is the load on the processor(s). Smaller usually equals lighter.
In the Swiss Army approach once you start the program there goes a ton of memory and processor usage.
Programmers/Coders/Hackers can probably elaborate this simplistic point.
Originally posted by ipodandimac
which in turn means Mail supports LDAP, since Address Book and Mail are indeed integrated.
If only I could figure out how...
I have Entourage working just great with my Exchange 2003 server, but the same settings will not work in Apple apps like Mail or Address Book. I don't mind using Entourage (especially now that it has Spotlight support), but I always preferred Apple's apps.
Originally posted by TednDi
If I may add one point.
In CC's collaborative component approach, the memory usage in smaller apps is much lower as is the load on the processor(s). Smaller usually equals lighter.
In the Swiss Army approach once you start the program there goes a ton of memory and processor usage.
Programmers/Coders/Hackers can probably elaborate this simplistic point.
Yes and no.
A well designed "swiss army knife" application can load stuff on demand and unload as things are not used to manage this more properly.
I think there are pros/cons to both approaches, but I tend to much prefer the approach Apple uses.