A route page has to answer the whole journey
A schedule page earns trust when riders can tell which route it describes, which direction it covers, and when its times apply. A timetable without that framing can leave a basic question unanswered: does this information match the trip I intend to take? For a US transit information website, the design challenge is to organize route details so that the same page structure can support different services without implying live departures, ticketing, booking, or direct operator data.
This article proposes an original CMS design study for an owner-related website. It does not describe a completed project, a current feature set, or measured improvement. The practical aim is one reusable route-page model that makes key schedule context visible before a rider relies on a time.
Model service context as structured content
A proposed route record should include a route identifier, route name, direction, timetable source, timezone, service date, exceptions, and verification date. Editors could enter these as distinct fields instead of burying them in a single rich-text block. WordPress supports registering custom post types and rendering their content publicly; that documentation provides a reference for separating a repeatable content type from ordinary pages, but does not prescribe this particular transit schema. [1]
Treat schedule applicability as content, not decorative fine print. Each published timetable should state the timezone and the date or date range it covers. An exception field could explain holiday service or other known variation, with a clear statement when no exception has been supplied. A visible verification date would give readers and editors a shared cue about when the page was last checked; it would not itself guarantee that an operator has made no later change.
Make weekday and holiday ambiguity explicit
Consider an illustrative case: a route table lists weekday times, and a visitor opens it on a public holiday that falls on a weekday. Does “weekday” include that date? A proposed page should not make the rider infer the answer from the table. It could show a concise applicability note such as “Weekday timetable; holiday service may differ—check the listed operator information,” followed by the service date and any verified exception details. This is proposed microcopy, not a claim about a real route.
The publishing checklist should ask an editor to confirm route identifier and direction; confirm the timetable source and timezone; record which service dates the table covers; review applicable exceptions; and set a verification date. If a source cannot establish an exception, the page should say so plainly and direct the rider to the official operator as final authority. This workflow is a suggested safeguard, not documented execution.
Design a readable mobile and keyboard flow
On a narrow screen, a wide timetable can force side-to-side movement that makes row and column relationships difficult to retain. A proposed mobile layout could place route identity, direction, service-date note, and exception status before the times, then present timetable entries in a compact sequence with stop and time labels repeated as needed. Test the result at narrow viewport widths with long stop names and multiple time values; these are proposed test conditions, not observed defects.
Keyboard users should be able to reach the route context, schedule, exceptions, and operator reference in a predictable order. Use clear headings, meaningful control names, and text alternatives for any informative graphics. WCAG 2.2 frames accessibility around perceivable information and operable interfaces, including text alternatives for non-text content; applying those principles here is a design recommendation, not a conformance finding. [2]
Validate the model before expanding it
A first practical step is to prototype one route page from the proposed fields and ask several readers to identify direction, applicable service date, timezone, and the next official source to consult. Record where each person hesitates, then revise labels and hierarchy. A second step is to have an editor publish a sample weekday timetable and a holiday exception using only the checklist, noting any field that invites an unsupported assumption.
These exercises would evaluate comprehension and publishing consistency; they would not establish ridership outcomes or schedule accuracy across a whole network. If the model is adopted, the next useful review is a small set of route pages with different directions and service exceptions. That review can show whether one schema remains clear across variation before wider content migration is considered.
Sources & useful references
Results are attributed to the original publisher. Proposed tests and creative recommendations are our analysis.
