Designing a calendar people actually read

Our old calendar was a page of announcements in reverse chronological order. It was accurate, maintained, and almost never used by students. The problem was not the information. It was the shape.

Start with the questions

People arrive at a calendar with one of three questions:

1. What is happening today?
2. What is happening while I am on campus?
3. Is this event for someone like me?

A list can answer the first question if the user scrolls far enough. A month grid answers all three at once, because the structure of the week is visible before any text is read.

Model the event, not the announcement

Each event is now a Markdown entry with a fixed set of fields: date, optional start and end time, location, category, audience, and an optional registration link. The body is still available for the detail page, but the listing only relies on structured fields.

That separation is what lets the same content appear in three places without being rewritten: the homepage preview, the month grid, and the event detail page.

title: Ordinary cities: a public lecture
date: "2026-11-12"
startTime: "18:30"
endTime: "20:00"
location: Great Hall
category: Lecture
audience: Open to the public

Keep the editable surface small

Editors do not need a page builder to add an event. They need a form with the right fields, a preview, and a publishing path they already trust. The calendar collection in GitCMS provides exactly that, and the site build validates every entry before it goes live.

The result is less impressive than a bespoke events platform and much easier to keep. For a university our size, that is the right trade.