[OGo-Users] Re: [OGo-Developer] Changes to trunk, Testing

[Adam Tauno WIlliams]

> But the inability to select groups when creating new 
> appointments, or when editing them, makes it not really useful.

Agree,
 
> > I can envision some setups where it _might_ make sense (when there are  
> > really _large_ quantaties of equal objects, eg chairs in a conference  
> > room), but as Adam suggests this is really overkill and probably a  
> > different software altogether (inventory management).
> actually, we use this to order soft-drinks, cookies, ...
> So then I'm back on the bool field, "Ignore conflicts" for such resources. 
> It would be great, if I could specify that for a given resource conflicts 
> should be ignored.

I think the solution there is to make resources more like normal
participants,  they can then be assigned an info-only role and shouldn't
create conflicts.

> So instead of having resource groups Coffee, Soft-drinks, cookies, each 
> containing resources coffee1-10, cookies1-10...
> I could have a resource group Catering, where I then have resources coffee, 
> soft-drinks, cookies. this would make the the booking of such resources way 
> more clear. People get confused, and waste time, when they have too much 
> possibilities to choose from.

I really seems to me that you need to just create a custom front-end for
this specific purpose of organizing these types of meetings.  I
recommend that over making the basic scheduler UI yet more complicated;
especially given that [looking at my systems] 9 out of 10 appointments
are VERY simple with only one or a few participants.  Handling
sophisticated scenario's is important but one must keep in mind the
demographics of the problem domain (most appointments are simple, so
keeping features from getting in the way of those is important).

> Also it is annoying, when there is a conflict, and I want to send mail after 
> appointment creation, then only the creator is in the list of mail 
> recipients. When there is no conflict, all participants are in the list of 
> mail recipients. I think I have an open bug report for that.

Yep, I think I remember seeing one.

> Yes, they should take the proposal interface, but they don't do, no idea 
> why.

Insufficient training. :)  Really, we face the same thing, some users
find scheduling endlessly frustrating.   I chalk most of this up to "PIM
disease",  where they just don't get the difference between the retarded
little calendar in sunbird/outlook/palm-desktop and groupware.  Of
course the retarded little calendar won't do anything to help solve
their issue with seeing if a conference room is available from 9 to 10,
or tell them they've just scheduled an appointment with someone who is
on vacation, etc...  There are just inherent complexities with groupware
that PIM doesn't have [because PIM is stupid],  a good UI can ameliorate
lots of that, but never completely.  One bit of advice I have after
awhile of dealing with this just relates to the basic use of language
while training: *never* say "my calendar", "your calendar", etc... say
"the calendar" and always, relentlessly [to the point of being annoying]
correct users when they use the possessive grammar.  Seriously, it
helps.

> > Resources require a rework anyways. Its more likely that resources  
> > will become another SQL-view on top of the company table to enhance  
> > consistency with iCalendar. The 'kits' would probably become  
> > resource-'teams' quite naturally. Not sure how one would represent  
> > resource categories. We'll see once we actually implement it ...
> Oh, when will this happen? ;)