Markdown Blogging Platform for Students with Drafts and Tag Search

Markdown Blogging Platform for Students with Drafts and Tag Search is a web application that lets students write study notes and project diaries in Markdown and publish them as readable posts. Many students already keep notes in plain text, yet plain text loses headings, lists, code blocks and tables when it is shared, so notes become hard to scan and harder to revisit. Copying notes into a slide deck or a document editor fixes formatting but hides the original text and makes small edits slow. This platform keeps the plain-text source as the single version of the work: the author writes Markdown, the platform renders it into a clean reading page, and the same source can be edited again at any time. Drafts protect unfinished writing, tags organise posts by topic, and tag search returns only the posts that carry a chosen tag, so a reader can move from a collection to one relevant post without scrolling through everything.

Concept: one plain-text source, rendered two ways. The editor view shows the Markdown source beside its rendered preview, and the reading view shows the same rendered post without editing controls, so writing, reviewing and reading never require three separate copies of the same post.

The Markdown blogging platform turns plain-text writing into a published post through a short, repeatable sequence. An author opens the editor, enters a title and a few tags, and writes the post body in Markdown, using headings for structure, lists for steps, code blocks for commands or snippets, and tables where a comparison helps. As the author types, the preview pane renders the same text, so headings, bold text, inline code, code blocks, lists, blockquotes, links and tables can be checked immediately. Saving stores the post as a draft, which stays private and editable. Publishing changes its status so it appears as a published post in the list and in tag search results. A reader then types a tag, opens a matching post, and reads it in the reading view, where the reading time is shown beside the post tags.

1. The author opens the editor and enters a post title and comma-separated tags that describe the post topic.
2. The author writes the post body in Markdown, using headings for structure, lists for steps, code blocks for commands or snippets, and tables where a comparison helps.
3. The preview pane renders the same text beside the editor, so headings, bold text, inline code, code blocks, lists, blockquotes, links and tables can be checked before anything is published.
4. The author saves the post as a draft, which keeps it private, editable and clearly labelled as a draft in the post list.
5. When the post is ready, the author publishes it, changing its status so it appears as a published post in the list and in tag search results.
6. A reader types a tag in the search box, and the post list filters at once to the posts that carry that tag.
7. The reader opens a matching post in the reading view, which shows its title, tags and estimated reading time above the rendered body, and the author can edit or delete the post from that view.

Builder note from the demo build: a table row containing a pipe character inside inline code broke the first version of the table parser, which split every row on every pipe character. The shipped parser splits table rows only on pipe characters outside backtick code spans, and fenced code blocks are kept as raw text so Markdown inside a code block is never rendered as formatting. In first-principles terms, Markdown-to-HTML rendering here is a text-to-text transformation: the parser classifies lines, escapes raw HTML, then applies inline rules, so post content stays inert text until it is rendered.

Tech stack:

• HTML · CSS · JavaScript (editor, preview and reading views)
• Node.js · Express (web server and post API in the delivered build)
• SQLite (post, tag and status storage in the delivered build)
• Markdown parser (line-based block parsing with inline formatting)
• Git (version control)

The platform centres on four capabilities that work together: a Markdown editor with live preview, a draft and publish workflow, tagging with tag search, and a reading view with reading time. The editor shows the rendered post beside the source text, so formatting mistakes are visible before anything is published. Drafts let an author save unfinished work privately and publish only when it is ready, while the post list keeps drafts and published posts visibly separate. Tags describe each post in a few words, and typing a tag in the search box filters the list to matching posts at once. The reading view presents the published post without editing controls, with its tags and an estimated reading time, so a reader knows what the post covers and how long it will take before starting it.

• [Markdown editor with live preview] The author writes headings, lists, bold and italic text, inline code, fenced code blocks, blockquotes, links and tables in Markdown, and the rendered post updates beside the source as each line is typed. Implemented in the base build.
• [Drafts and publishing workflow] A post can be saved as a draft, edited again later, and published only when the author is ready, with drafts and published posts shown with different status labels in the post list. Implemented in the base build.
• [Tagging and tag search] Each post carries comma-separated tags, and typing a tag in the search box filters the post list to the posts that carry that tag, so a reader can narrow a collection by topic in one step. Implemented in the base build.
• [Reading time and word count] Every post shows an estimated reading time beside its word count, computed from the post body at a stated reading assumption, so a reader can judge the length of a post before opening it. Implemented in the base build.
• [Post management] The author can open any post for editing, change its title, tags or body, save it again as a draft, publish it, or delete it from the post list. Implemented in the base build.
• [Clean reading view] A published post opens in a focused reading page that shows its title, status, tags and reading time above the rendered body, without editor controls distracting from the text. Implemented in the base build.
• [Sample student posts] The demo ships with sample student posts covering debugging notes, a study explanation and a project diary, so the editor, tag search and reading view can be demonstrated immediately after setup. Implemented in the base build.

Optional customizations (not in the base build): user accounts with login, comments on posts, image uploads inside posts, and scheduled publishing. Future scope (not implemented): full-text search across post bodies, post series that group related posts, and export of a post to a printable document.

• Complete web application source code (editor, preview, post list and reading view)
• Markdown parser with headings, lists, code blocks, tables, blockquotes, links and inline formatting
• Draft and publish workflow with tag search and reading time
• Sample student posts as starter content
• Setup guide for running the application locally
• Project report PDF (background, design, parser working, methodology, limitations)
• PPT presentation for final review
• Viva Q&A preparation document (Markdown parsing, rendering pipeline, draft workflow, storage design)

Timeline

• Week 1: requirements, editor layout, live preview and the Markdown parser core.
• Week 2: draft and publish workflow, SQLite storage, and post management (edit and delete).
• Week 3: tagging, tag search, reading view with reading time, and sample student posts.
• Week 4: testing across posts and edge cases, setup guide, report, PPT and viva Q&A.

Support

• Setup guidance for running the application locally, a walkthrough of the editor, preview, draft workflow and tag search, and fixes for defects found in the shipped build during the handover review.

Requirements

• A modern web browser for the editor, preview and reading views
• A Node.js runtime for the delivered server build
• SQLite for post, tag and status storage in the delivered build
• No paid service, external account or cloud subscription is required for the base build