feature request: improved "availability" indication for multi-participant events

unknown commented

2026-09-01 14:15:42 +00:00

The original description was not recovered.

Referenced by commits

coffey-labs/ihasmail@e1402e472f 2026-09-01 Schedule against the whole guest list, and say who cannot be read
coffey-labs/ihasmail@c4649e0084 2026-09-01 Say what the availability bar is showing, and show all of it

_{Rebuilt from: notification email, session transcript. Opening date is approximate.}

*The original description was not recovered.* **Referenced by commits** - coffey-labs/ihasmail@e1402e472f05 2026-09-01 Schedule against the whole guest list, and say who cannot be read - coffey-labs/ihasmail@c4649e008479 2026-09-01 Say what the availability bar is showing, and show all of it <sub>Rebuilt from: notification email, session transcript. Opening date is approximate.</sub>

mbunkus commented

2026-09-01 14:15:42 +00:00

Yeah I've seen your efforts. Not sure if that's at all relevant for us or our customers; they tend to have stuff on prem on which they deploy things (read: it's really us doing it for them). But still, having more options is always nice, and our use-case is definitely not the be all, end all.

jcoffey-dev commented

2026-09-01 17:47:30 +00:00

Owner

All three parts are in now — #182 for the labels and the multi-day span, #183 for the scheduling panel. Both merged; they'll go out with the next deploy.

Parts 1 and 2. The bar carries an axis: hours every three across a single day, every six across two, day names beyond that, with the marks drawn down the bars so a busy block can be read against the hour it starts at rather than hovered for a tooltip. And it now covers whole days from the day the event starts to the day it ends, with the free/busy lookup asking for the range it draws — it really was hard-coded to the start day and 24 hours. A week is as far as it stretches; beyond that it says how many days it left out rather than drawing a month at eight pixels a day.

Part 3 is a panel in the event editor: a row per participant, stepping backwards and forwards a screenful at a time without touching the event, with a way back when you have wandered off.

On not making it a separate view. You asked for one and I want to explain the departure rather than have you find it.

The first reason is where the question gets asked. "When can we all meet" is asked while arranging the meeting, and a separate view means leaving what you are doing, reading a grid, coming back, and re-entering by hand what you just learned. The panel sits under the guest list, a few lines below the fields it is about.

The second reason is what that proximity buys, and it is the part I would not give up: because the event is right there, the grid is somewhere to put it. The pointer shows the half hour it is over, and clicking moves the event there keeping its length — including when you have stepped days away, in which case the event moves to where you clicked and the view stays with it. A standalone view can only ever tell you a time that you then retype. That is the difference between something you read and something you use, and it exists only because the event is in the same dialog.

The third is that a second surface keeps costing after it is built: another route, another copy of the guest list, another thing to keep in step with the editor and to lay out again on a phone.

What a separate view would genuinely add is browsing availability with no event in hand — "when is everyone free next week?" as a question in its own right. That is a different question from "when shall we hold this one", and if it is one your colleagues actually ask, it is worth its own issue and I would build it as such.

One thing worth knowing, which your report did not raise but a scheduling grid forces. Free/busy is answered per principal, and only accounts on the server are principals — so for anyone outside it, there is nothing to read. Previously such guests were quietly left out of the bar. In a grid that would be actively misleading, because a row with nothing in it reads as a diary with nothing in it, and "we cannot see this person's calendar" must not look like "this person is free". They now get a row drawn hatched, with a line underneath saying how many and why.

I checked this against a live server rather than assuming: free/busy between accounts is answered without any sharing being set up, and a principal exposes no route to its calendars at all — so free/busy is not the weaker permission, it is the only channel there is. The hatching is therefore permanent honesty about what the protocol can see, not a gap waiting to be closed.

Your own row is included too, first, and always readable — scheduling around everyone except yourself is how two things end up at the same time.

All three parts are in now — #182 for the labels and the multi-day span, #183 for the scheduling panel. Both merged; they'll go out with the next deploy. **Parts 1 and 2.** The bar carries an axis: hours every three across a single day, every six across two, day names beyond that, with the marks drawn down the bars so a busy block can be read against the hour it starts at rather than hovered for a tooltip. And it now covers whole days from the day the event starts to the day it ends, with the free/busy lookup asking for the range it draws — it really was hard-coded to the start day and 24 hours. A week is as far as it stretches; beyond that it says how many days it left out rather than drawing a month at eight pixels a day. **Part 3** is a panel in the event editor: a row per participant, stepping backwards and forwards a screenful at a time without touching the event, with a way back when you have wandered off. **On not making it a separate view.** You asked for one and I want to explain the departure rather than have you find it. The first reason is where the question gets asked. "When can we all meet" is asked *while* arranging the meeting, and a separate view means leaving what you are doing, reading a grid, coming back, and re-entering by hand what you just learned. The panel sits under the guest list, a few lines below the fields it is about. The second reason is what that proximity buys, and it is the part I would not give up: because the event is right there, **the grid is somewhere to put it**. The pointer shows the half hour it is over, and clicking moves the event there keeping its length — including when you have stepped days away, in which case the event moves to where you clicked and the view stays with it. A standalone view can only ever tell you a time that you then retype. That is the difference between something you read and something you use, and it exists only because the event is in the same dialog. The third is that a second surface keeps costing after it is built: another route, another copy of the guest list, another thing to keep in step with the editor and to lay out again on a phone. What a separate view would genuinely add is browsing availability with **no event in hand** — "when is everyone free next week?" as a question in its own right. That is a different question from "when shall we hold this one", and if it is one your colleagues actually ask, it is worth its own issue and I would build it as such. **One thing worth knowing, which your report did not raise but a scheduling grid forces.** Free/busy is answered per principal, and only accounts on the server are principals — so for anyone outside it, there is nothing to read. Previously such guests were quietly left out of the bar. In a grid that would be actively misleading, because a row with nothing in it reads as a diary with nothing in it, and "we cannot see this person's calendar" must not look like "this person is free". They now get a row drawn hatched, with a line underneath saying how many and why. I checked this against a live server rather than assuming: free/busy between accounts is answered without any sharing being set up, and a principal exposes no route to its calendars at all — so free/busy is not the weaker permission, it is the only channel there is. The hatching is therefore permanent honesty about what the protocol can see, not a gap waiting to be closed. Your own row is included too, first, and always readable — scheduling around everyone except yourself is how two things end up at the same time.

mbunkus commented

2026-09-01 18:42:03 +00:00

On not making it a separate view

The reason why I pasted that OX screenshot was only to serve as a point of reference or inspiration, not as a thing to copy as-is. I'll give your implementation a serious try & will most likely be perfectly fine with it, so thank you.

"When can we all meet" is asked while arranging the meeting, and a separate view means leaving what you are doing, reading a grid, coming back, and re-entering by hand what you just learned.

Valid. In OX the workflow is different than your assumption, just for the record. In the calendar view there's a separate button that directly opens the planning view, not the "new event" view. In the planning view you can add participants & find a suitable time frame. Once you're satisfied you can launch the "new event" view from the planning view, carrying over the participants & the selected start timestamp & duration.

"when is everyone free next week?" as a question in its own right

Me personally I don't ask that question without the intent of creating an event, though I acknowledge others might do. If there are such people, they can ask & argue for it themselves — I'm perfectly fine with "when creating a new event, when is everyone free?"

The third is that a second surface keeps costing after it is built:

That's always a valid reason to reject a FR in my book, don't worry 😁

Free/busy is answered per principal, and only accounts on the server are principals — so for anyone outside it, there is nothing to read

I am aware of that, yes. That's just like in OX, and we're fine with that limitation. As will be our customers, I bet.

I don't necessarily need that planning view. I need more overview than what your prior solution gave me, hence me opening this issue.

Your own row is included too

Essential, yes. Thanks.

Looking forward to giving all the new features a try tomorrow!

> On not making it a separate view The reason why I pasted that OX screenshot was only to serve as a point of reference or inspiration, not as a thing to copy as-is. I'll give your implementation a serious try & will most likely be perfectly fine with it, so thank you. > "When can we all meet" is asked while arranging the meeting, and a separate view means leaving what you are doing, reading a grid, coming back, and re-entering by hand what you just learned. Valid. In OX the workflow is different than your assumption, just for the record. In the calendar view there's a separate button that directly opens the planning view, not the "new event" view. In the planning view you can add participants & find a suitable time frame. Once you're satisfied you can launch the "new event" view from the planning view, carrying over the participants & the selected start timestamp & duration. > "when is everyone free next week?" as a question in its own right Me personally I don't ask that question without the intent of creating an event, though I acknowledge others might do. If there are such people, they can ask & argue for it themselves — I'm perfectly fine with "when creating a new event, when is everyone free?" > The third is that a second surface keeps costing after it is built: That's _always_ a valid reason to reject a FR in my book, don't worry 😁 > Free/busy is answered per principal, and only accounts on the server are principals — so for anyone outside it, there is nothing to read I am aware of that, yes. That's just like in OX, and we're fine with that limitation. As will be our customers, I bet. I don't necessarily _need_ that planning view. I _need_ more overview than what your prior solution gave me, hence me opening this issue. > Your own row is included too Essential, yes. Thanks. Looking forward to giving all the new features a try tomorrow!

feature request: improved "availability" indication for multi-participant events #172