We know that these are issues and we're working on addressing them.
Specifically:
* The calendar/contact split was not adequately advertised in ReadMe or ORK
was a bug.
* That if you had calendar/contact synching by Category didn't split the
calendar accordingly on upgrade is a bug.
* There are some ease-of use issues when you're trying to use a Calendar not
associated with your account (e.g., the local Calendar when receiving
Exchange-based invitations and updates).
* That there is no unified Calendar view.
I've written some comments inline.
-nh
OK Nathan, then let's use your exact words:
Not asking you to speak for the program management staff, just your honest
opinion: You don't find it completely embarrassing that NOBODY there would
expect that a user might want to use only the local calendar?!? Or at least
want a single comprehensive calendar view (list views don't count, as
they're basically useless for "looking" at a calendar). ESPECIALLY with
SP2's erratic placement of events into either calendar, and not correctly
updating invitations or modifications to events? I can name 30 people in my
company alone that have this problem.
I do not believe that "nobody here would expect that the user might want to
use only the local calendar", so it's hard for me to find that non-existant
state "completely embarrassing". I just did not personally expect that
people would want to use the local calendar for Exchange-based invitations.
Exchange has a permanent Calendar folder for such events, and to use a
different folder breaks the Exchange paradigm. That isn't to say it isn't
worthwhile, but we'd have to _add_ customizability.
As for "erratic placement of events", it should be deterministic.
* If the invitation came in from Exchange-mail, it'll go onto the Exchange
calendar.
* If it was just created, then if the current account is an Exchange
account, it'll go onto that Exchange account's calendar, and otherwise onto
the default mail account's calendar (which is either Exchange or the local
calendar for non-Exchange accounts)
* If it was opened from an .ics or .vcs file, it should go onto the default
mail account's calendar.
If it is not doing that, it's probably a bug. If you think that the design
is "erratic", was there some alternate design that wouldn't require extra
custom settings (like a per-Account setting of "Use this calendar")? Custom
settings didn't make it into the schedule.
It's pretty obvious that one might want a single comprehensive calendar
view; it just didn't make the schedule.
On my personal machine, I've traced this back to an issue where, prior to
the SP2 "update," I had events in a certain category sync'd with Exchange.
Now, since the update, I have NO WAY of rescinding this; those events (that
used to reside in my Local calendar) are now forced into the Online
calendar. More infuriating, if those events are moved to the local calendar,
any updates received will create new events in the wrong calendar.
The category synch issue is clearly a bug.
Do you receive updates to that event on your Exchange e-mail? Or elsewhere?
In the case of the former, per above, we'd expect the event to live in your
Exchange calendar. In the latter, we should be looking at your default mail
account, and if it's Exchange, using that calendar. If it's not working
according to that logic, it's a bug.
Sorry Nathan, you're gonna have a hard time convincing me that this glaring
issue is a minor, excusable oversight.
OK, again... I want to make sure that I'm understanding your exact words
correctly:
So it's OK to radically change the way the program works, adding an
additional calendar without notifying users of the irrevocable change in
operation once the database is converted? And the programmers were actually
AWARE that there would be no way to view all events at one time, but it was
more important to enable Exchange technology and make people use separate
calendars until they can fix the viewing problem?
Largely correct. Lack of notification was bad form. Database upgrades have
always been (and probably will always be) irrevocable, so there's nothing
new there -- back up your data before upgrading! You can view all of your
events using a custom view, but since that's in table format rather than
calendar format, it's not quite the same.
OK Team, we've got the engine and the gas pedal working great! Let's get
that "out the door" to our customers, then we'll get right to work on
perfecting a brake pedal for the next update. You know... one step at a
time.
I do not understand how you can consider this to be a reasonable analogy. I
don't worry about Entourage hopping the curb and killing pedestrians.
Furthermore, the event add/update problem only affects an incredibly small
section of Exchange customers: Exchange users who don't use their Exchange
calendar or wish to use their Exchange calendar for non-Exchange accounts.
Even multiple calendar users can switch back and forth between calendars to
view events. It's not a showstopper for either subset of users, whereas not
having a brake pedal is a showstopper for every driver.
And in regard to the database being unsearchable... sorry, I misspoke. I
meant to tell Michelle that it is unsearchable using Apple's integrated
Spotlight Search Engine, that has been hailed in reviews as revolutionary,
and is able to search EVERY other file on my computer. So Michelle, if
you're still listening... the Entourage database is completely searchable...
as long as you don't want the search results to relate to any other files on
your computer. Hope that clears it up.
Spotlight support is in the works. Support for it and other new-to-Tiger
technologies were announced at MacWorld 2005, though they have been delayed
due to some interoperability concerns.
http://www.microsoft.com/presspass/press/2005/jan05/01-11Macworld2005PR.mspx
In closing, let me state that it is not my intent to flame about this.
However Nathan, you seem focused on defending Microsoft's indefensible
position with these multiple calendars that were forced on users with no
warning. This has basically screwed a few dozen people at my company, and
until your program management team resolves it, we spend wasted time every
day manually resolving conflicts between our new "bonus" calendar installed
by the SP2 Update. It has resulted in missed appointments, double-booked
group meetings, etc, etc. Aggravating, and never a problem before the SP2
update.
Could you explain this a little more; we'd like to understand the scenario a
little better so that we know we're really addressing your problems:
* How do group meetings get double-booked? If you're talking about resources
(rooms, a/v equipment) using the auto-accept and auto-decline agents on
Exchange, it shouldn't matter what calendar is being used in Entourage. Are
you talking about invitee's free time not being reported correctly due to
events on their local calendar?
* How do appointments get missed? Entourage should alert you for
appointments for both the local and Exchange calendar.
* What are the conflicts you are seeing? Are users accepting events for
which they are not free, because there's another event accepted on a
different calendar? Something else?
Until it's resolved, consider yourself _self-maligned_. Your own words do
more damage than I ever intended to do. I just came here looking for
answers, and a simple acknowledgement that "we know it's a mistake and we're
working hard to fix it as quickly as possible" would have gone a long way
toward that cause.
sw
Personally, I think explaining what is going on is an honorable thing, so I
don't feel like I've maligned myself at all. The bugs I've mentioned are
mistakes, but the design choices we made involved tradeoffs. These tradeoffs
aren't always easy to evaluate, even after the decision was made, the work
completed, and the product shipped. I'm still pretty sure that the design
was not a mistake, even if it had negative consequences for some users -- by
far, more people were helped.
That said, let me reiterate what I said at the top: We know that these are
issues and we're working on addressing them.