GroupWise 8’s “Auto-Accept Appointment” Behavior
I was recently contacted by a fairly large GroupWise 8 customer about the “Auto-Accept Appointment” behavior that was added to GroupWise 8. Prior to GroupWise 8, if I sent an appointment and included myself in the attendees, I would either have to create a rule to accept my appointment, or I would have to manually accept it myself. With GroupWise 8, this was changed to automatically accept the appointment if I sent it to myself.
Now, while this is an okay functionality for me personally, it has caused quite a stir among some of my customers. We’ve put together a quick poll to see what your thoughts are regarding this feature. Please take the quick poll at http://www.caledonia.net/blog and also comment here with why you chose the answer you did. Why do you like this? Why do you hate this? It’s important for you to comment, because just saying “I hate it” isn’t enough to get Novell to address the issue. The Novell engineers will need to have a better picture of “why” this is a problem for your organization in order to possibly reevaluate this change.
My opinion remains the same: Do not change an existing default behavior unless it becomes a selectable option. It would have been just fine to change this if the behavior could have been managed by a simple options entry.
What do you think?
Danita
Hi Danita.
Well, IMHO this is realyl a non-question. Common sense implies that such a behaviour shouldn’t be changed without making it at least configurable. It is no problem for me personally, but I’m perfectly certain there are a lot of others for whom it is. Someone somewhere certainly has some procedure or application that depends on the original behaviour.
I also have to say, I can’t answer your poll really, because no possible answer matches that. I do not dislike it, but it really *must* be configurable.
Good point Massimo! And since the poll has just started, I’ve added an additional entry for this since it won’t skew the results at this point!
You’re missing one selection from your poll. I like the auto accept feature very much, but I also think it should be configurable. That’s not an option on your poll so I just selected I like it and it’s fine the way it is…which isn’t exactly how I feel.
I selected the last one that it should be configurable. I’m a HUGE fan of the auto-accept feature (no more rule needed – woo-hoo!), but we have some users who really dislike it. IMHO they’re using the client the wrong way, but I’m not “warm and fuzzy” enough for our users, so configurable would be a nice middle-of-the-road option.
The biggest issue we’ve run into with the auto-accept feature is that apparently (according to our users) you are no longer notified if there is a scheduling conflict. Otherwise, they seem okay with the ability to get a message in their mailbox via an optional check box.
I guess I’m just with Massimo that I fail to see why changes like this don’t trigger a “configuration” option. I mean, they have to code something differently to make the change. Why not just code a check box into the Preferences as well at that point?
I’ve always had a rule that auto-accepts appointments I create, so really for me it was just a shrug. But I knew even from the moment I saw it that there would be pushback from some customers about it.
Perhaps this will teach people to do a busy search before they hit send 🙂
This is a case where engineering thinks they know better than the customer. Too bad engineering doesn’t realize that the customer essentially is paying their salary.
I think this kind of change is alright (for those who use it) but it should be configurable. In my 3000+ user email system, I don’t know of any users who setup a rule to auto-accept their appointments. A change like this may been seen as a benefit, but more likely not. Thus, I think the default should be off and that it be a configurable option if someone chose to use it. As someone else pointed out, configurable would be a nice middle-of-the-road option. In addition, I agree with what Danita wrote “Do not change an existing default behavior unless it becomes a selectable option.”
Configurable by all means. Saves time having to explain the difference and train the Users. I agree with Mary in regard to the scheduling conflict issue. This has caused missed and over scheduled appointments. Novell most likely received several enhancement requests for this option. There also, although I cannot duplicate, is an issue with the appointment not even showing up on the Senders Calendar.
I’ll not weigh in on whether the feature change is OK or not, I personally like it tho. However, I think I can at least add something to the discussion from a development standpoint. Yes everyone wants every feature to be configurable, however this would probably increase development time by at least twice if not more, depending on if the configuration is just in the client or also a ConsoleOne Client Options option.
Also, I’m 90% or more sure that this change probably didn’t happen just cause dev thought it would be cool, I’m sure there were a number of requests from customers to make it auto-accept.
My 2 cents.
Mostly it’s my users who don’t like it. Aside from the unexpected behavior apparently some of them prefer the visual assurance that what they sent out got to posted to the other recipients also. Unfortunately the workaround, to keep the accept/decline copy in the mailbox is more like a threatening trigger. If you accidently delete it during a cleanup or deliberately do so to dismiss the clutter, it causes the appointment itself to get removed.
For myself, I hate having to explain this all to my users. I’d rather it be a configurable switch at the administrative level.
I like it. I did have two users who were alarmed that the old behavior vanished the day after the upgrade. Two out of 4,000 isn’t so bad.
I don’t need the client side Tools –> Options –> Calendar –> General “On accept, continue to display the item in the Mailbox” exposed via ConsoleOne. What would have helped though, is if the GW 8 Readme had a section for “End user experience changes: what you user’s need to know”.
Mostly my users disliked having to accept their own appointments, and now it’s handled automatically. However, while I also like the new feature, I would have preferred to have a selectable option that could be turned on/off for the user/PO/Domain. That way, everyone can be satisfied and work they way they want to. Which, as I remember, was a catch cry of Novell’s last year.
This should be a client option. Here’s our list of business cases. The “option” to keep messages in your mailbox after accept is not a solution, especially when our people are scheduling several resources (10+), and schedule them for the whole year in advance. Our CIO is NOT happy.
User responsible for scheduling multiple resources -They use the mailbox item to track how many people have accepted the appointment. If enough staff accepts, the room is scheduled otherwise it is kept open.
User responsible for scheduling multiple administrators -Staff responsible for scheduling one or multiple administrators use the mailbox item in their own mailbox to track the attendees of the meeting for that administrator.
User double schedules him/herself -No warning of conflicts.
User schedules for the wrong date in the past
User schedules too few appointments
We have tried to keep our ear to the ground on this issue. We realized, when we made the change, that some users would be dissatisfied.
Last March – I also blogged on this exact topic – along with a few other changes.
http://www.novell.com/communities/node/7074/groupwise-8-feedback
Quoting from the blog:
“We have also considered providing an option. I will go out on a limb and say that is what most feedback will probably be. Simply…if some users like it one way and other users like it another, then simply provide an option. In general, this is a good philosophy and in many many cases, this is exactly what we do. However, it is never that simple. First of all, we would need to ultimately provide the option in every client. Windows, Linux/Mac, WebAccess. Shortly after we provide that, the request would come that the administrator wants the option to set it, lock it and control it. Then 3rd-parties would request API support for the option so that they could incorporate it into their solutions and account for it in their products. This also has localization costs and usability costs. Some might argue we already have way too many options. Most of which are never touched by 80% of our user base.”
I have read all of the comments in this blog with much interest. Thank you for your feedback…we really do listen and want to make the best decisions. The opportunity costs here must also be considered.
Dean