Dinesh/ Blog
← All articles
cloud engineering

Improving the UI of this blogging app - V2

Changing the UI layout and improving the experience by modernizing the UI with custom styling

6 min readChecking device speech…
Lesson preparation & details

Level: beginner

Application engineering projects · Lesson 3 of 6 ↗
Loading this browser’s progress…

By the end, you should be able to

  • Stored preference is system, operating system is dark, then the OS switches to light. What changes?
  • Explain the version and execution boundaries before applying the examples

Bring with you

  • Basic programming and HTTP; follow the chapter or cloud-track sequence

Editorial review: · What review means

In this article · 6 sections

Review and execution boundary

Framework-independent theme-state and publishing regression lesson; historical screenshots are not UI-test evidence.

Reviewed on 7 October 2026 against the official source snapshots linked below. The review is bounded editorial correction, not certification of every dependency, security property or cloud deployment. Historical setup commands and optional exercises were not executed. No cloud resources, third-party packages or external side effects were created. Old screenshots and unavailable private assets remain in the private recovery archive, not prerequisites for this lesson.

Improving and Enhancing the UI of this blogging app with the same functionalities.

Current UI functionalities and experience

The goal for V2 was to change how the blog looks without changing how posts are written or parsed. The first three sections establish the baseline: a date-sorted index, rendered Markdown and the per-post content folder. That makes the later redesign a comparison of presentation, not a migration of the publishing workflow.

  • 1.Home Page:

Simple layout with blogs sorted with date parameter passed in content.md file.

  • 2.Blog Page:

The blogs are direct implementation of markdown converted to html using md.convert. The conversion and testing is already done and running as expected (parsing images, bolding, headers formatting, links embedding) so the parsing is working as expected. The incremental blogging will be done by creating a folder in blogposts and writing down markdown files with content.md and other assets.

https://www.markdownguide.org/basic-syntax/

  • 3.Blogging input method:

Version1 branch with all the code until this implementation so that we can revert to this version in future if needed.

https://github.com/dinesh-coderepo/blogsite/tree/version1

As mentioned already the input method is markdown by creating a folder for each blog and adding content.md with the content and other assets.

  • 4 .Made changes to the UI using cursor:

With that publishing path unchanged, I used Cursor prompts to revise the layout, spacing and visual theme. The new homepage screenshot is the visual comparison with the earlier index; the changes listed below also extend to article and translator pages, which one homepage image cannot verify.

The most revealing implementation problem was the light/dark toggle. Adding a switch was not enough: its position and selected state had to mean the same thing across every page, with the preference retained between visits.

  • Note:
    • Cursor made many mistakes while implementing the toggle feature.
    • Consistency was missed between pages on which side the slider would be on each page. This solution required many iterations with cursor prompts to get right.
    • Always assume you will never reach 100% of what you want with the prompts, so having domain knowledge of these technologies is still important if you do not want to compromise on implementation.
    • For my blog, the achieved format looks good for the second version. I will keep iterating the blog to newer versions and add functionalities as well going forward.

Summarizing the changes made to the UI:

  • Implemented a consistent dark/light mode toggle across all pages:

    • Added a sliding toggle switch with sun (light mode) and moon (dark mode) icons.
    • Ensured the toggle works consistently across blog index, individual blog posts, translator input, and translator results pages.
    • Implemented local storage to remember user's preference.
  1. Redesigned the background for a more fluid and visually appealing look:

    • Created a gradient background that transitions smoothly from dark to a slightly lighter shade.
    • Added subtle radial gradients and a fine grid pattern for depth and texture.
    • Implemented a glassmorphism effect for containers and blog posts, with blur effects and slight transparency.
  2. Improved the blog index page (index_blog.html):

    • Enhanced the layout with better spacing between elements.
    • Added differentiation between blog posts using CSS Grid with gaps.
    • Styled each blog post with its own container, subtle background, and hover effects.
    • Positioned the translator section at the bottom with proper styling and separation.
  3. Updated the individual blog page (blog.html):

    • Maintained consistency with the index page styling.
    • Improved readability of blog content with proper spacing and formatting.
  4. Enhanced the translator pages (index_translator.html and results_translator.html):

    • Aligned the styling with the blog pages for a consistent look.
    • Improved button styling and layout.
    • Added a "Go to Home" button on the results page for better navigation.
  5. Implemented responsive design:

    • Ensured the layout adapts well to different screen sizes.
    • Used max-width for containers to improve readability on larger screens.
  6. Typography and color improvements:

    • Used the Roboto font family for a modern, clean look.
    • Implemented a color scheme with primary and accent colors that work well in both dark and light modes.
  7. Added subtle animations and transitions:

    • Implemented hover effects on buttons and blog post containers.
    • Added smooth transitions for color changes when switching between dark and light modes.

The result is a second visual iteration over the same Markdown publishing workflow. The toggle problem is the main lesson: a page can look correct in isolation while behaving inconsistently during navigation. A useful regression path is to switch themes on the index, open an article, visit the translator and reload; the selection should remain consistent throughout. The screenshots document the appearance, but they do not by themselves verify that behavior or every responsive layout.

Corrected contracts and failure analysis

A theme has one semantic state shared by every route. Persist the preference as light/dark/system; resolve system mode from the media query and keep the stored preference distinct from the effective theme. Storage can be unavailable, so a failed localStorage write must not break navigation. Server-rendered apps need an explicit initialization strategy to avoid a flash or hydration mismatch.

A visual redesign can preserve Markdown input while still breaking heading anchors, dates, image paths and code blocks. Record a content fixture before changing CSS or rendering. Test the route sequence index→article→translator→reload, plus keyboard focus, reduced motion, long code and zoom. A gradient screenshot cannot establish responsive or accessible behavior. Use a stable toggle label with aria-pressed, or an action label without toggle semantics; do not conflate the two.

Boundary exercise with solution

Stored preference is system, operating system is dark, then the OS switches to light. What changes?

Solution and reasoning

The effective theme changes to light while the stored preference remains system. If preference is explicitly dark, an OS change does not override it. Verify all routes derive from the same state and storage failure leaves a usable default.

Source-backed review notes

  • ARIA: aria-pressed attribute - ARIA | MDN — accessed 2026-10-07. Exact supporting passage: “The aria-pressed attribute indicates the current "pressed" state of a toggle button.”
  • useEffect – React — accessed 2026-10-07. Exact supporting passage: “When Strict Mode is on, React will run one extra development-only setup+cleanup cycle before the first real setup. This is a stress-test that ensures that your cleanup logic “mirrors” your setup logic and that it stops or undoes whatever the setup is doing. If this causes a problem, implement the cleanup function.”

Pause / Recall / Apply

Can you explain it without the page?

Close the example. Reconstruct the core idea, then change one assumption. Mark complete when you’re ready; you can always undo it.

Stored in this browser only. No account, no sync. Clearing browser data removes your record.