Before ND6 and the wonderful @SetViewInfo, there was a single, huge, and to all intents and purposes, fatal flaw with the Notes calendar view, and just about every developer I know found out about it the same way — when a rather rude messagebox let them know in no uncertain terms that the first column had to be a date-time and the second had to be a duration, and that Designer didn't want to hear any of their whining and/or complaints. You simply cannot categorize a calendar view, at least not in any way that would allow you to use RestrictToCategory. That means that you needed to create separate views to cover any "categories", and that a new keyword in the database meant that somebody needed to create a new view and link to same.
Like most, I found that to be good reason for complaint, and I was fixin' to let somebody at Lotus have an earful. Then (as happens far too often) I tried to understand the reason why things were the way they were. I occurred to me (as it should occur to you if you give it some thought) that the calendar you look at in the client has absolutely nothing to do with the view you create in Designer, at least at the most basic level. The calendar is just a table, nothing more, nothing less, generated by a relatively dumb perpetual calendar generating routine. The content of that table (after the dates and format have been determined by the "dumb" routine) are taken from the view you created. By lookup, if you hadn't guessed, with the date and duration acting together as lookup keys. That's why you can't sneak another column into the most valuable real estate.
"Two can play at that game," he muttered.
What I needed was a way to generate a table that looked like a calendar, and a way to populate that table with data. The first part isn't all that difficult; after looking at several completely different months on a broad spectrum of commercially-available and private, highly-classified intelligence and military calendars, I came to the inescapable conclusion that what would be required would be a table that was seven cells wide. The first row of that table would have between zero and six "blank" cells, apparently representing days that are, for whatever reason, not to be included in the current month. That would be followed by between twenty-eight and thirty-one numbered cells, arranged so that if one of those cells were in the rightmost of seven cells, the following numbered cell would appear in the leftmost cell of the row below. In the case where the last numbered cell of that month did not appear in the rightmost cell of its row, there should be precisely enough blank cells added to that row as to complete the row. Any idjit can do that using Formula Language to create HTML. And any idjit did, and he saw the calendar, that it was pretty and regular and everything a calendar should be except fast.
What made me an idjit is that I took the lookup idea too far. Did you now that 31 @DbLookups on a single form makes the form slow? So did I, but I did it anyway. Why? Well, how else are you supposed to get the information into the calendar table before you send it out to the browser? Besides, the calendar I made was just so much prettier than what Domino gives you out of the box.