Undergraduate Thesis Formatting Guide (Series Sample) 01: Cover Page, Abstract, and Table of Contents — Why They Must Look “Like This”

Forget “because the handbook says so” for a moment. The front matter exists mainly to serve three tasks (and three audiences):

1. Identification: Who wrote it? What’s the title? Which school/department? Which year? — for archiving, spot checks, plagiarism checks, and statistics.
2. Navigation: Reviewers rarely read from page 1 to the end. They skim the abstract and TOC first, then jump into the sections they care about.
3. Process: Printing/binding and electronic submission systems require a stable structure (fields, order, hierarchy).

When you see rules like “cover page fields must be complete”, “abstract should be a standalone page”, or “TOC must show hierarchy”, they exist to reduce the cost of these three tasks.

---

Think of your thesis as a working interface. In the first 30 seconds, a reviewer is not “reading prose”; they are doing fast orientation.

A typical scan path looks like this:

Cover Page (confirm identity) → Abstract (confirm topic & method) → TOC (confirm structure & completeness) → Jump to key sections

So the formatting goal of front matter is not “pretty”. It’s:

• Controllable information density (key fields are visible at a glance)
• Clear hierarchy (which line is the title vs. author/department info)
• Low jump cost (TOC and page numbers are trustworthy)

---

3.1 The cover page is not for display; it’s for identification and archiving

Fields on the cover page (title, name, student ID, department, major, advisor, date, etc.) are closer to a stable “metadata card” than a design poster.

The requirement is simple: someone should be able to identify what this document is within 5 seconds from a printed copy or a PDF screenshot.

3.2 Common visual constraints, and what they are really for

• Aligned fields and consistent spacing
• Reason: reviewers and archive staff “scan fields”. Alignment reduces eye movement and search effort.
• The title dominates; other fields are secondary
• Reason: the title is the discussion/search anchor; name/department are archival anchors.
• Avoid decorative elements (background images, heavy lines)
• Reason: printing/scanning and automated extraction introduce noise; some systems try to detect text blocks.

3.3 Use a simple “block diagram” to explain why the cover looks this way

(This kind of explanation is where your content becomes genuinely original.)

[Thesis Title (most prominent)] [Author info block: name / ID / department / major] [Advisor block: advisor / unit] [Submission info: date / location]

You don’t need to publish precise fonts/margins in this article (schools differ), but you should make the block structure explicit.

---

4.1 The real reader of an abstract is a “decision reader”

The abstract supports a decision:

What is the research about? How was it done? What did it find? Is it worth reading further?

So the abstract should look like a “mini-report”, not like an extension of the main body paragraphs.

4.2 Common formatting constraints (principles, not school-specific numbers)

• The abstract is presented independently (often on its own page)
• Reason: easier for submission systems to extract and for reviewers to copy; also easy to distribute/print separately.
• A stable “Keywords” block
• Reason: keywords support indexing and classification; they are machine-friendly fields.
• Structured abstract (Purpose/Methods/Results/Conclusion) is more common in empirical disciplines
• Reason: it matches reviewers’ evaluation workflow and reduces information loss from “story-like” abstracts.

4.3 Variants (to expand in later articles)

• Whether Chinese/English abstracts are both required, and whether they must be paginated separately, varies by school/department templates. Don’t over-claim here; instead, list the common variants so readers know what to check.

---

The TOC is not decoration; it is visible proof that your structure is complete and navigable.

Reviewers use it to:

1. Check whether key sections exist (methods/results/conclusion)
2. Check whether the hierarchy is reasonable (depth not out of control)
3. Jump directly to what they want to read (page numbers must be reliable)

5.1 Visual constraints and why they matter

• Consistent indentation per level
• Reason: hierarchy should be visible without reading every line.
• Same-level headings must look the same
• Reason: TOC is navigation; consistency beats personal styling.
• Stable, aligned page numbers
• Reason: page numbers are the TOC’s core value; unstable numbers make the TOC effectively useless.

5.2 A highly “original” angle: typical ways a TOC fails

This is a great place to start an “anti-pattern library” (add 1–2 anti-patterns in each article of the series):

• Headings are manually bolded/indented, so TOC generation becomes unreliable
• TOC is not updated; page numbers disagree with the body
• Heading levels are misused (same level appears with multiple different styles)

This kind of content is more helpful than generic “how to insert a TOC”, and it naturally leads to “check before submission”.

---

This is the most natural entry point for a format checker: we avoid product talk and focus on verifiable standards.

6.1 Cover page acceptance criteria (principle level)

• Required fields are present (title / author / department / major / advisor / date, etc.)
• Information blocks are grouped clearly (not a single paragraph of mixed fields)
• The title has the highest visual level (clearly distinct from field text)

6.2 Abstract acceptance criteria

• The abstract can be read independently (not relying on “see Chapter 3” to explain basics)
• A keywords block exists
• Minimum structure elements are present (Purpose/Methods/Results/Conclusion at least covered)

6.3 TOC acceptance criteria

• The TOC is generated from heading styles (traceable, not manual)
• Indentation is consistent within the same level
• Page numbers are aligned and updated (TOC matches actual pages)

Key idea: readers should be able to self-check without tools; tools only automate self-checking.