Shared rooms and equipment
Booking shared rooms, labs and equipment
Shared facilities are scheduled by many people who each care about a small part of the calendar: a trainer looking for a room with twenty seats, a researcher who needs an instrument for six hours. The schedule has to help them find what fits and stop them from taking more than the rules allow.
Many bookers, shared rules
Unlike a clinic diary or a dispatch board, there is rarely one planner. Bookings come from instructors, project teams and individual researchers, each with their own priorities. The facility manager sets the rules: who may book which resource, for how long, how far ahead, and what must happen between bookings.
Resources differ in ways a name does not show. Rooms have capacity, layout and equipment, and some can be divided in two. Instruments need warm-up, calibration or cleaning; some require a trained operator, and a few are booked through an approval step.
Recurring use dominates. A course meets every Tuesday for twelve weeks and a lab group holds a standing slot, so ad hoc bookings have to fit around those series without anyone losing track of either.
What bookers and facility managers decide
- 01
Which room or instrument fits
Matching capacity, features and location to the request, and comparing the shortlist side by side on the same days.
- 02
How long a booking may be
Maximum durations, booking horizons and per-group quotas keep one team from monopolizing a shared instrument.
- 03
What happens between bookings
Calibration, warm-up, cleaning or a room reset must sit between users without being booked over.
- 04
How to handle a divisible room
Booking the full hall blocks both halves; booking one half leaves the other available.
- 05
Moving a series when a room closes
When a room is unavailable for a week, every affected session needs a new home, ideally in one operation.
Modeling shared resources
Rows are bookable rooms or instruments with their attributes as columns, events are bookings with an owner, and the facility rules run in your handlers and on your server.
- Resources
- Group rows by building and floor, or by instrument family. Row header columns show capacity, equipment or location, and rows.filter with onRowFilter narrows the list to rooms with enough seats or instruments of the right type.
- Events
- Each booking carries its owner, group and purpose as custom fields. Preparation or calibration is either a locked event of its own kind or, when it follows a fixed timetable, a range of disabled cells, so it cannot be booked over.
- Time scale
- Training rooms read well in hourly cells across a week, instruments in hours across a few days. Saved view state restores each user’s zoom, scroll position and collapsed groups; your application stores it alongside any filter.
- Rules
- In onTimeRangeSelecting and onEventResizing, set args.allowed to false with a message when a booking exceeds the maximum length or falls outside the booking horizon. Use multi-selection to move several sessions at once when a room closes.
What the timeline enforces, what the facility system owns
- Row filters, columns and grouped resources for finding a fit
- Refusal of selections and resizes that break a rule, with a message
- Disabled cells for calibration, service and closures
- Multi-selection and moving several bookings at once
- View state you can save and restore per user
- Custom rendering of booking and instrument status
- Identity, groups and who may book which resource
- Quotas, approvals and booking horizons as enforced rules
- Recurring series, expanded into individual bookings
- Divisible-room logic, where one booking blocks related rows
- Storage of saved views, notifications and cost recharging
Working examples
Problems shared calendars run into
Rules that live only in the interface
A refused selection guides honest users; it does not stop a direct request to your API. Every limit the timeline shows must also be checked on the server.
A recurring course as one long event
A single bar from September to December blocks every hour in between. Expand the series into sessions so each one can be moved or cancelled.
Unstable row ids
Saved views remember the top row by id. If rooms are renumbered or ids are generated on each load, restored views land on the wrong rows.
Forgetting the other half of a divisible room
A booking on the full hall must block both halves, and the reverse. Check related rows in your validation; the timeline only knows about the row being dropped on.
Questions
How do I stop people booking an instrument for more than four hours?
Check the length in onTimeRangeSelecting for new bookings and in onEventResizing for changes, and set args.allowed to false with a message such as “Bookings are limited to 4 hours”. Enforce the same limit on the server.
Can each user save their own view of the schedule?
Yes. getViewState from super-scheduler/views returns a JSON-safe description of zoom, scroll, density, collapsed groups and column widths, and applyViewState restores it. Your application decides where to store it, for example per user in your backend.
How do I model calibration or cleaning time after a booking?
Either create a locked event after each booking, with moveDisabled and resizeDisabled, or include the buffer in your overlap check so the next booking cannot start until it has passed. The first is visible to everyone; the second keeps the grid quieter.
Does SuperScheduler support recurring bookings?
The recurrence options are reserved and have no effect. Expand each series into individual events in your backend, with a shared series id, so your application can offer “change this session” and “change all following sessions”.
Two facilities demos
Morrow changes a classroom session and checks which rooms are free at the same time; Benchlab books instrument time with a preparation window. Both organizations are fictional.
Working examples