One big hurdle to overcome is making this work with non-Notes Invitees (or Chairs). While it is possible to convey a new Chair in iCalendar, no known iCalendar implementations support the concept of actually changing the chair from another system.

This is primarily due to there being no secure way to confirm this change in the standards. Without a secure way to verify a change, users could find their meetings being hijacked which would be more harm than good.

There are potential workarounds for this such as simply Canceling and recreating the meeting w/the new Chair but they require every users participation to keep the meeting intact. (Plus it can get very messy when dealing with repeating meetings.)

If there was no requirement to work for _all_ invitees of a meeting (Notes and non-Notes) then this idea would have a greater chance of becoming reality.

A few tidibts to consider:

1: The 'hotspots' on the left are intended for users to select a _specific_ room or resource they want. The meeting date/time are flexible but the room requirement is not. Users are expected to use the scheduler UI to confirm availability of the room.

2: The Find buttons on the right are intended for users to _search_ for any available room or resource. The meeting date/time is typically fixed but the room requirement is flexible.

3: We used to provide both actions from the Action bar as separate actions ("Find a room" and "Select a room" I think) but they got pulled out and reworked as part of some UX work.

4: As of 8.52 the mail template will double check the R&R availability when Save and Send is clicked so you do not waste time trying to book a busy room or one that will immediately Decline your request!.

5: The room restriction info _is_ in the NAB. It is just not displayed it seems if you access the record in the NAB directly or use the Details button on the botton left corner of the 'hotspot' dialog. Feel free to tweak your NAB design to show the AutoprocessUserList item value if its there and that will show you who can book it.

6: The "Do not enter" icon is too overloaded. It is meant to convey "restrictions exist". I agree that it would be better if we had unique icons for different kinds of restrictions. Unfortunately we are limited in the available icons. If someone would like to provide some design changes to differentiate "Owner only" from "Specific Users", etc then great! (Color coding alone does not cut the mustard due to accessibility concerns.)

7: As of 8.52 or maybe 8.53, if you are not on the "allow" list for a room, you will not be given that as a choice when you search for a room. Any rooms that appear as "Info Restricted" will not be offered as a room suggestion. Couple that with the busytime check added during Save & Send which will tell you that your room choice is not available to you, you should have a very clear picture that the room you chose is not available to you.

If you have not tried the usability improvements in 8.52 and 8.53, you really should. Of course we are always interested in hearing how to make it better and easier so keep the ideas flowing.

Bruce

The concept of a 'resource pool' from which the staff pulls which ever available resource and provides it is a concept few have asked for so it never gets any attention by those who bless feature requests.

Resource searching ("Find me a "Projector" at the Westford Site") seems to work for most customers. The users only really have to get back any available matches and then pick one. Most don't seem to care that they are picking the specific one in the UI. The only time the current model does not work smoothly is when the staff have to replace one resource with another (assuming they actually match the resource to the request every time). However I have not heard many complaints about the current way things are so changes are likely to be slow in coming there.

I would be interested to hear some thoughts/suggestions on how to best represent this 'non-reservation' time in both views and the UI.

For exmaple: the Chair only requests a meeting from say 9AM - 10AM but the room crew needs 10 minutes to cleanup/reconfigure. In the views should it show I requested 9AM - 10AM or 10:10AM? In the busytime search, should the UI distinguish that 10 minutes as separate from the meeting (so its clear to those looking that the room is being serviced?) or squish it into the same entry (so you see "Details for 9AM - 10:10AM" in the GUI)?

I like having a different color but that can be problematic for screen readers and other similar systems (plus the GUI is not great at showing small differences such as between 10:10 and 10:15, esp. on smaller sized screens)

Oh to be fair, there should also be some form of "prep" time added for rooms which could be useful as well. Then it gets harder to juggle things. Can the 'cleanup' time overlap with the next entrys 'prep' time? (I bet there are feelings on both sides of this too.)

I was under the impression that you could drag/drop .ICS URLs onto your Calendar (or anywhere in the mail file????) and it would import them; they do NOT have to be local.

I thought this was in there since R6 or R7...

Cant check my client now but try using drag/drop from your web browser and see if it works.

Because users do not know what is in an .ICS you do not want them to accidentally blow their Calendar up with all kinds of junk (Calendar spam anyone?). That is why there is a UI for selecting which entries in an .ICS to import. (Lets leave aside the concerns about reimporting the same content from different .ICS files for now.)

I do grant that the import feature could use some more love although in what way is a bit fuzzy. I will also point out that an .ICS can be a bundle of many entries from different .ICS files (just copy them into 1 and try it). There are also changes coming in 8.x (I forget which .x) related to .ICS and Calendar subscriptions which is what this sounds like you are doing.

It seems clunky to me that if the client already knows that at least a Room is not available it get in the users face and say "Hey, I just told you the Room A is not free at the time you want. Pick another time or another room!". After all what good is it to know the user will just get an immediate Decline notice back which they may or may not see and do nothing to prevent them from getting frustrated later on??

This will cease to be an issue as your older, pre-R7 repeating reservations age out and the Purge Agent removes them.

The basic reason for why you see this is the pre-7.0 Rooms & Resource (R&R) design was to use the "R5" style of repeating reservation encoding; 1 document for an entire run of repeating dates.

As of 7.0, the R&R system uses the older "R4.5" style of repeating encoding: 1 document per repeat instance. This makes maintenance simpler and it also avoids keeping potentially very old reservations around needlessly.

Once the last pre-R7 reservation is 2 days past the last repeating date, the clutter will be all gone and your views more "current".

This should not be necessary as of 7.0 with the entire redesign of the Rooms & Resources (R&R) system. The new Rooms & Resource Manager (RnRMgr) task has sole control over both request processing and busytime updates so the system has none of the older designs weaknesses.

For a good overview, check out the Lotusphere 2005 presentation on the new system (along with a design overview of the older system to help everyone better understand the changes and why they were done).

The primary design objective of the new R&R system is to NOT allow double bookings. If you have deployed 7.x (or 8.x) then you should not get any double bookings. Preexisting double bookings are not corrected but no new double bookings will be created.

If you are using 7.x/8.x and you are getting any new double bookings, open a support ticket ASAP so we can investigate it.

This feature was added in 7.03 and 8.0. It should have been TechNote'd but if not I will correct that (and post a follow up here).

Making the text truely only visible to the Chair is not possible if they can use Document Properties to view any item. So here lies the rub...
If you keep the data there so only the Chair can see it (via some Hide When formula) then any user w/half a brain can bypass it and see the data anyway.
If you use Reader lists to hide the doc to avoid the InfoBox peekers then it appears as if R&R is 'broken' because "I dont see any meeting for 9AM - 9:30AM but the system says it is unavailable at that time!"
So the only answer is to truely remove the text but then whats the point of entering something only to remove it (and thus make it also hidden from the Chair)?
Perhaps some form of text packing/encoding so that only the Chair could decode it would work but that would probably take more cycles than its worth.
Still, I would love to hear some suggestions on dealing with this better....

This ability is partly there already.
If users reserve rooms from their Calendar (the preferred method) then the "Private" option is sent on the reservation request. It is detected and respected by the RnRMgr which will zap the Subject/Topic to "[** Private entry. The description is not available for display. **]" so even the use of the InfoBox will not expose the private info.
For users who direct book, they simply do not need to put in a meaningful Description.
It would seem a bit odd to have users specify a sensitive Description and then click a "Mark Private" checkbox only to have the text disappear... (If you try to hide it via scripts, it could still be read by InfoBox so its not really hidden is it??)

I created a tool to address this years ago. It is posted in the Sandbox of the old Notes.net site (now developerWorks?). Search for "nocal.exe" or go directly here: { Link }

Due to how different sites want to keep dBs around long after an employee is gone but they do not like the warnings on the console, this tool was designed to just make the dB invisible to Schedule Manager (or the Rooms & Resource Manager but PLEASE do not use on your R&R dB since your rooms are not likely to be fired anytime soon...)

If you have your NABs set up to share your R&R entries (or you build the EDC properly) then you can do cross domain R&R without any problems. We have been using it that way for years that way.
The default EDC settings are missing 6 R&R related items you need but the data is in the NAB. I believe there is a technote on what to add to your EDC list to make it just work.
If you do not use EDCs, then all you need to do is have your NABs replicate across domains and configure their proper use in the other domains.