Complete guide
Four ways to publish a timetable, and who each one is for
Every institution ends up using more than one of these. The mistake is choosing one and assuming it covers everybody.
The four routes
They are not alternatives so much as different distances from the reader.
A web address is the plain one, and it is the one to print. The institution's timetable website carries the whole schedule, filtered by whoever is looking; a link with a selection in it opens exactly the timetable you meant to send, and a link with no date in it stays correct all year — which is what makes it safe on a noticeboard or behind a QR code outside a lecture room.
An embedded view is the same thing inside your own faculty page, for readers who should never have to leave it. Give it room: a week grid wants roughly 900 pixels before it collapses into a narrower layout.
A calendar subscription puts the timetable inside the application somebody already has open all day. It updates itself, and it is the right answer for staff. How the feeds work.
The mobile application is the only one of the four that can reach somebody who is not looking.
- A link — public, printable, and correct all year
- An embed — the same view inside your own pages
- A subscription — inside the calendar people already live in
- The app — personalised, and able to interrupt
Publishing is not notifying, and the difference costs money
A web page and a calendar feed are pull media. The reader has to come and look, or their calendar has to go and re-read. Neither can originate a message, which means neither can tell anybody that something has just changed.
That is not a small distinction in practice. A calendar feed can update silently overnight; the student who looked yesterday walks to the old room in the morning. Publishing the change correctly and having nobody find out are the same outcome for the person standing outside the wrong door.
So an institution that only publishes has solved half the problem. The half left over is notification — a push to the phones of exactly the people affected, and an e-mail to the ones who prefer it. What actually reaches a phone.
Which route for which reader
| Reader | What they need | Route |
|---|---|---|
| A prospective student or a visitor | To see that the institution has a timetable and roughly what it looks like | The public web address |
| A current student | Their own schedule, on a phone, with changes reaching them | The app, with the web address as the fallback |
| A lecturer | Their teaching beside their meetings, without a second place to look | A calendar subscription |
| A departmental office | One room, or one programme, at a glance | A link with the selection in it, or a room feed |
| Somebody standing in a corridor | The next hour in this building | A signage screen |
| An external examiner, once | One week, now | A downloaded file — the only place a download is the right answer |
Three things that go wrong
A file sent instead of an address. Somebody exports a term and e-mails it round in September. It is a photograph, it never changes again, and nobody who has it knows that.
A link with a date in it. It opens on that week for ever. Print one on a noticeboard and it is wrong from the second week of term.
Publishing a schedule nobody was told about. The most common of the three, and the least visible: the timetable is correct, the website is correct, and the students are still asking the office where their class is — because nothing ever announced that any of it existed.
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.