DEV Community: Awoyemi Abiola

Luminary - IWD Project

Awoyemi Abiola — Sat, 07 Mar 2026 10:43:02 +0000

Introduction

It's the month of March, and the month of International Women's day, and at the Rise Academy frontend track, we've been split across 3 teams to work on impactful projects solving real problems women in society - Nigeria and Africa more specifically - face today.

One of these projects which I was assigned to and would be writing about is Luminary.

Luminary is a community-powered directory and news platform celebrating women who are driving change across all fields — business, science, arts, activism, sport, technology, agriculture, education, and more. It allows anyone to nominate or self-submit, is searchable by name and field, and surfaces daily and weekly news of women making impact globally.

My Team and I would be working over the next few weeks to bring Luminary to life, for this week, we created the Landing page. I would be writing about how it went, my role in the project, and the lessons I learned so far.

Week 1

Project Setup Phase

The setup phase for the project started out with each team member getting a role assigned, we are all primarily frontend developers on the project, but all have a supplementary role to manage one aspect of the project,
available roles were;

Product Lead: Owns the PRD, scope, and feature prioritisation.
Engineering Lead: Oversees technical architecture and approves all PRs into the prod branch.
Design Lead: Owns the Design System, logo, and UI consistency.
Lead Maintainer: Manages the repository and branching strategy.
Backend Lead: (Borrowed from other tracks) Manages API integration and database schema.
People Manager: Manages workflows, team synergy, and escalates issues to the instructor.

Once we had our roles assigned, the Lead maintainer, Isaac Shosanya created the repository to manage the project, I was assigned the role of Product Lead along with Ramnan Ramyil and we worked on the product documentation and feature prioritization. Other team members carried out their respective roles and documentation. A designer from the design track joined the team and helped create a Figma design file for the landing page. Once the foundation for the project was complete, we begun development.

My Contributions as Product Lead and Frontend Engineer

As a Frontend engineer on the project, I worked on the Hero section of the landing page, it consisted of a header text, a cta, image and some metric information for Luminary, using placeholder numbers for now.

As a Product Lead, I also carried out the following;

Onboarded team members to our project channel on the project management tool being utilized - ClickUp
I created custom task statuses that would align our project management process closer to our development processes
I added tasks and assignees for each member to the ClickUp board
I recorded a walkthrough video for the full task completion pipeline, from issue creation -> feature/task completion, and all that is required of team members in between.

Lessons Learned

So far, I have learnt and picked up improvements to writing commit messages from the standards in the documentation laid down by our Lead maintainer.

Week 2

Specific Features Implemented

This week I developed the UI and API integrations for Nominations of other women via a Nomination form on the application;

Built the full nomination form UI.
Integrated backend APIs for frontend consumption during nomination and self-submission form submissions.

Technical Implementation Breakdown

Form UX logic: Implemented tab switching between nomination and self-submission panels, section collapse/expand accordion behavior to match designs precisely, and dynamic link inputs.
Image preview: Added file preview rendering in the thumbnail circle using the FileReader API.
Payload mapping: Transformed UI inputs into the backend payload shape .
Submission flow: Added async JavaScript fetch integration with status feedback and error handling.

BaaS Tool and Integration

We chose Supabase as our BaaS. I reviewed the nomination service and payload requirements, and matched the frontend submission shape to match the Supabase-backed tables as expected on the backend for nominations, nominee & nominator.

Challenges & Resolutions

Field mismatches between UI and API: The backend expected first_name/last_name fields, so I added name-splitting logic for to match the required payloads.
Handling two form modes: I scoped dynamic elements and payload building to the active panel so both nomination and self-submission submit correctly.

What I Learned This Week

This week, from my work on the submissions flow for nominations, I learnt how to integrate API requests for complex form structures and improved my skills with UI DOM and Data manipulation in Frontend development.

Week 3

Specific Features Implemented

This week I worked on the admin-side management interfaces and the user-facing news experience for the application;

Built the admin nominations management UI with filtering, approval and rejection actions.
Developed the admin news article interfaces, including the add article page and shared admin sidebar behavior.
Built the user-facing news listing page and linked it into the existing user navigation.

Technical Implementation Breakdown

Admin nominations dashboard: Implemented a responsive nominations table and card view, filter controls, action menus, and status badges to support moderation workflows.
Backend integration for moderation: Reviewed the nomination service and related admin routes, then connected the frontend list, search, approval and rejection actions to the authenticated backend endpoints.
Reusable admin shell: Refactored the sidebar styles and JavaScript into shared files so the same layout and active state behavior can be reused across admin pages.
News experience UI: Built the add article page for admins and the public news page for users, using clean mock data and responsive image handling to match the provided designs closely.

BaaS Tool and Integration

We continued using Supabase through the existing backend layer. For this week, I reviewed the nomination admin service, controller and routes, and mapped the frontend moderation UI to the backend responses so nomination records could be fetched, filtered, approved and rejected correctly from the admin interface.

Challenges & Resolutions

Matching backend data to the UI structure: The nomination data returned from the backend needed normalization before it could fit the table design, so I mapped nested nominee and nominator fields into a frontend-friendly shape.
Reusable navigation across admin pages: The sidebar active state did not initially work consistently across routed pages, so I updated the matching logic to normalize paths and moved the sidebar code into shared files for reuse.

What I Learned This Week

This week, from building both the admin tools and the public news experience, I learnt more about integrating authenticated frontend flows with backend endpoints, structuring reusable UI logic across multiple pages, and translating design mockups into responsive interfaces that are easier to extend as Luminary grows.

Week 4 - Final Retrospective

4 Weeks of back-to-back collaboration and development and we're finally at the finish line, for now at least. It has been a great sprint and I can say we've been able to achieve a great product at the end of it, let's dive in to the details for this week's coverage while looking back at the project as a whole in retrospect, after you...

Specific Features Implemented

This week I focused on integrating a headless CMS into the application and shipping final polish across the frontend;

Built a custom Sanity CMS client layer and article service module to power dynamic news content across the application.
Refactored the entire frontend codebase folder structure for JavaScript, CSS, and HTML pages to improve maintainability.
Fixed responsiveness issues on the article page, featured sections, and nomination forms.
Added landing page animations and a loading state for the articles feed.
Resolved lingering bugs including hero image rendering, nomination payload formatting, and broken navigation links.

Technical Implementation Breakdown

Sanity CMS client: Built a lightweight, SDK-free integration layer (sanity.js) that exposes GROQ querying, document mutations, and image uploads against Sanity's HTTP API, keeping the frontend dependency-free.
Article service module: Created articles.js on top of the client layer with functions to fetch published articles, retrieve a single article by slug, and render article cards into the DOM dynamically.
CMS integration across pages: Connected the CMS service to the news listing page, individual article page, featured stories section on the landing page, and the admin add-article flow so content is now managed from Sanity rather than hardcoded.
Codebase restructuring: Reorganized the JavaScript, CSS, and HTML files into cleaner folder hierarchies, updating all import paths and script references across the application to match.
Bug fixes and polish: Fixed the nomination form to correctly pass profile images in the payload, added remove buttons for dynamic link inputs, corrected hero image paths and optimized the hero asset to a lighter format.

Challenges & Resolutions

Keeping the CMS integration lightweight: Rather than pulling in the full Sanity SDK, I wrote a minimal client using native fetch and URL construction, which kept the bundle lean and gave full control over how queries and mutations are handled.
Coordinating the folder restructure with active development: Restructuring the file hierarchy while other team members had open branches required careful communication and path updates to avoid merge conflicts across pages, styles, and scripts.

What I Learned This Week

This week, from building the CMS integration and wrapping up the sprint, I learnt how to integrate a headless CMS into a vanilla JavaScript application without relying on framework-specific SDKs, and improved my understanding of GROQ as a query language for content APIs.

Sprint Retrospective

A milestone worth celebrating

Over four weeks, we took Luminary from a blank repository to a fully functional community platform, a searchable directory of women driving change, a moderated nomination pipeline, and a CMS-powered news experience — all built by a team of frontend developers learning to collaborate across product, engineering, and design roles.

What went well

Clear role ownership from day one meant each team member knew what they were responsible for, which kept decisions moving and reduced bottlenecks throughout the sprint.
Incremental integration over big-bang merges :shipping features in focused pull requests made code reviews manageable and kept the main branch stable.
The move to Sanity as a CMS gave us a clean content management layer without adding backend complexity, and the lightweight client approach kept the frontend simple.

What I would do differently

Set up a shared environment configuration earlier. Hardcoded API URLs and tokens caused unnecessary friction when switching between local and deployed environments; a centralized config from week one would have saved time.
Invest more in responsive testing early on. Several responsiveness fixes landed in the final week that could have been caught sooner with a mobile-first review step during each PR.

What surprised me

The amount of coordination required to restructure a codebase mid-sprint without disrupting teammates was more involved than I expected. It reinforced how important clear communication and small, well-scoped commits are when working on shared code.

Key technical lessons from the sprint

Integrating backend APIs with complex frontend form structures requires careful attention to payload shape alignment between what the UI collects and what the API expects.
A headless CMS can be integrated with just native browser APIs when the requirements are straightforward.
Reusable UI patterns like the admin sidebar and shared navigation should be extracted into shared modules early to avoid duplicated effort across pages.
Writing clean, conventional commit messages and maintaining a consistent branching strategy makes the codebase significantly easier to navigate as the project grows.

Shout-outs

A big thank you to the entire Luminary team for a strong sprint. To Isaac for keeping the repository and backend running smoothly, Daniel for thorough code reviews and architectural guidance, Ramnan for co-leading product decisions, Michael for the design system and UI consistency, Emmanuel for keeping us coordinated, and Ariyo for volunteering design support, and finally special thanks to Sophia Ahuoyiza, The Tabi and Rise Academy Team for facilitating all of this, It was a great experience building this together.

Contributors

-Product Lead 1: Ramnan Ramyil
-Product Lead 2: Awoyemi Abiola
-People Manager: Emmanuel Dania
-Lead Maintainer: Isaac Shosanya
-Design Lead: Michael Omonedo
-Engineering Lead: Daniel Chisom
-Backend Lead: Isaac Shosanya
-Volunteer (UI/UX): Ariyo Taiwo

Github Repository

Luminary

I'm not crying, you are

LovedIn: A Case Study

Awoyemi Abiola — Sat, 21 Feb 2026 12:10:32 +0000

Introduction

Hi, I'm Awoyemi Abiola, and this is my case study for the week 5 task of the Rise Academy Frontend track project - LovedIn, In this Case study, we'll cover what love challenges this project solves, who it solves it for, solution and UI design, technical structure and architecture of the project with HTML and CSS, and finally an overall reflection on collaboration and areas to improve. Let's dive in.

Problem Statement

In today's fast-paced digital world, expressing romantic interest has become increasingly complex and anxiety-inducing. Many individuals struggle with:

Finding the right words: The pressure of crafting the perfect romantic proposal or expression of interest often leads to missed opportunities or awkward encounters. People spend hours overthinking what to say, how to say it, and when to say it, which can result in never saying anything at all.
Personalization challenges: Generic romantic gestures often fail to capture the unique connection between two people, making them feel impersonal or insincere. A simple "Will you be my girlfriend/boyfriend?" text message doesn't convey the depth of thought and care that went into the decision.
Lack of memorable format: Traditional text messages or social media DMs lack the special, memorable quality that important relationship milestones deserve. These moments should be cherished and remembered, not lost in a sea of chat history.
LovedIn addresses these challenges by providing a structured, thoughtful, and personalized platform that takes the stress out of romantic proposals while maintaining authenticity and sincerity. It gives users the tools to express their feelings in a beautiful, memorable way.

The Primary target audience for LovedIn is a demographic of tech-comfortable young adults (18-35 years old) familiar with online dating culture and value creative and thoughtful expressions of affection.

Solution Design

To solve this problem, we designed a multi-page proposal website with:

Interactive Landing Page Experience
Personalized Information Collection via a form
An auto-generated and customized Proposal page

This flow was chosen to maintain a sense of emotional connection throughout the proposal creation process. Our users would not just be filling a form and getting a link but be crafting a thoughtful and romantic experience for their prospective partners.

UI Design System

Colors

The colour palette leans into romantic and affectionate tones. We aimed to create a visual mood that feels warm, gentle, and emotionally inviting. These colours were chosen to reflect love, softness, and intimacy without feeling loud or overwhelming.

Primary: #E22B3B [Scarlet Blush]
Secondary: #ED4779 [Wild Strawberry]
Accent: #FA88BB [Petal Frost]
Background: #F0D1D7 [Pink Carnation]
Support: #D86A77 [Blush Rose]

Typography

For fonts we sought after a font that was both expressive and somewhat simple, to balance romance with clarity and ensure emotional expression without sacrificing readability. After deliberation, we decided on Playfair Display for headings and Inter for body text.

HTML & Structural Approach

The website was built using semantic HTML to improve accessibility and SEO.

Key Semantic Elements Used

<header> for navigation and hero section
<main> for primary content
<section> for logical grouping
<footer> for closing content
<aside> for separate content

CSS Architecture

CSS Variables

To ensure consistency, I used CSS custom properties for colors, fonts, spacing values and transitions in a base css file shared across all pages in the application:

:root {
  /* ========== COLORS ========== */

  /* Primary Colors */
  --color-primary: #e22b3b;
  --color-primary-bg: #f0d1d7;

  /* Secondary Colors */
  --color-secondary: #ed4779;
  --color-secondary-bg: #fff6f8;

  /* Accent Colors */
  --color-accent: #fa88bb;

  /* Support Colors */
  --color-support: #d86a77;

  /* Neutral Colors */
  --color-white: #ffffff;
  --color-gray-50: #f9fafb;
  --color-gray-100: #f3f4f6;
  --color-gray-200: #e5e7eb;
  --color-gray-300: #d1d5db;
  --color-gray-400: #9ca3af;
  --color-gray-500: #6b7280;
  --color-gray-600: #4b5563;
  --color-gray-700: #374151;
  --color-gray-800: #1f2937;
  --color-gray-900: #111827;
  --color-black: #000000;

  /* ========== TYPOGRAPHY ========== */

  /* Font Families */
  --font-display: "Playfair Display", serif;
  --font-body: "Inter", sans-serif;

  /* Base Font Size */
  --font-size-base: 16px;

  /* Font Sizes - Type Scale */
  --font-size-xs: 0.75rem; /* 12px */
  --font-size-sm: 0.875rem; /* 14px */
  --font-size-md: 1rem; /* 16px */
  --font-size-lg: 1.125rem; /* 18px */
  --font-size-xl: 1.25rem; /* 20px */
  --font-size-2xl: 1.5rem; /* 24px */
  --font-size-3xl: 1.875rem; /* 30px */
  --font-size-4xl: 2.25rem; /* 36px */
  --font-size-5xl: 3rem; /* 48px */
  --font-size-6xl: 3.75rem; /* 60px */
  --font-size-7xl: 4.5rem; /* 72px */

  /* Heading Scales */
  --heading-h1: var(--font-size-5xl);
  --heading-h2: var(--font-size-4xl);
  --heading-h3: var(--font-size-3xl);
  --heading-h4: var(--font-size-2xl);
  --heading-h5: var(--font-size-xl);
  --heading-h6: var(--font-size-lg);

  /* Font Weights */
  --font-weight-normal: 400;
  --font-weight-medium: 500;
  --font-weight-semibold: 600;
  --font-weight-bold: 700;
  --font-weight-extrabold: 800;

  /* Line Heights */
  --line-height-tight: 1.25;
  --line-height-normal: 1.5;
  --line-height-relaxed: 1.75;

  /* ========== SPACING & SHAPES ========== */

  /* Spacing Scale - Padding/Margin */
  --spacing-xs: 0.25rem; /* 4px */
  --spacing-sm: 0.5rem; /* 8px */
  --spacing-md: 1rem; /* 16px */
  --spacing-lg: 1.5rem; /* 24px */
  --spacing-xl: 2rem; /* 32px */
  --spacing-2xl: 2.5rem; /* 40px */
  --spacing-3xl: 3rem; /* 48px */
  --spacing-4xl: 4rem; /* 64px */
  --spacing-5xl: 5rem; /* 80px */
  --spacing-6xl: 6rem; /* 96px */

  /* Border Radius */
  --radius-sm: 4px;
  --radius-md: 8px;
  --radius-lg: 12px;
  --radius-xl: 16px;
  --radius-2xl: 20px;
  --radius-full: 9999px;

  /* Border Widths */
  --border-width-thin: 1px;
  --border-width-medium: 2px;
  --border-width-thick: 4px;

  /* ========== SHADOWS ========== */

  --shadow-sm: 0 1px 2px 0 rgba(0, 0, 0, 0.05);
  --shadow-md: 0 4px 6px -1px rgba(0, 0, 0, 0.1);
  --shadow-lg: 0 10px 15px -3px rgba(0, 0, 0, 0.1);
  --shadow-xl: 0 20px 25px -5px rgba(0, 0, 0, 0.1);
  --shadow-2xl: 0 25px 50px -12px rgba(0, 0, 0, 0.25);
  --shadow-colored: 0 6px 20px rgba(226, 43, 59, 0.25);
  --shadow-subtle: 0 0 0 3px rgba(226, 43, 59, 0.15);

  /* ========== TRANSITIONS ========== */
  --transition-fast: 150ms ease-in-out;
  --transition-base: 250ms ease-in-out;
  --transition-slow: 350ms ease-in-out;

  /* ========== LINEAR GRADIENTS ========== */
  --gradient-primary: linear-gradient(
    135deg,
    var(--color-primary-bg),
    var(--color-secondary-bg)
  );
  --gradient-secondary: linear-gradient(
    135deg,
    var(--color-secondary-bg),
    var(--color-primary-bg)
  );
  --gradient-transparent: linear-gradient(
    rgba(255, 192, 203, 0.6),
    rgba(255, 182, 193, 0.6)
  );
}

This approach ensured consistency and cohesiveness for shared elements on the website, reducing repetition as much as possible.

Flex display was used across the application for a consistent layout and seamless responsiveness

  display: flex;
  align-items: center;
  justify-content: space-between;

A particularly challenging component was the navigation bar. My initial implementation for the navbar was not in tune with semantic standards, or a non-repetitive HTML structure. This was fixed and improved to take all these into consideration, keeping all links as direct descendants of the nav element.

      <div class="navigation">
        <a href="index.html" class="logo">
          <img src="assets/images/logo.png" alt="LovedIn logo" width="200" />
        </a>

        <nav id="nav-links-container" aria-label="Main navigation">
          <a href="#features" class="navlink">Features</a>
          <a href="stories.html" class="navlink">Stories</a>
          <a href="login.html" class="btn btn-primary auth-btn navlink"
            >Sign In</a
          >
          <a href="index.html#get-started" class="btn btn-primary navlink"
            >Get Started</a
          >
        </nav>
      </div>

.navigation {
  max-width: 1144px;
  margin: 0 auto var(--spacing-3xl);
  background: var(--color-secondary-bg);
  border-radius: var(--radius-full);
  padding: var(--spacing-md) var(--spacing-lg);
  display: flex;
  align-items: center;
  justify-content: space-between;
  box-shadow: var(--shadow-md);
}

#nav-links-container {
  display: flex;
  align-items: center;
  gap: var(--spacing-3xl);
}

Visuals

Responsiveness

JavaScript Implementation

Our application's interactivity is powered by three vanilla ES6+ JavaScript files app.js, proposal.js, and stories.js each scoped to a specific page with no external libraries or frameworks.

`app.js` Home Page Logic

Handles the landing page's proposal form and hamburger navigation menu.

Proposal Form Submission

Captures the partner's name and relationship type, validates both fields, then redirects to proposal.html with the values encoded as URL query parameters. Incomplete submissions trigger an alert.

Modal & Sharing

After a valid URL is generated, a modal offers two options: share via the Web Share API (with a clipboard fallback) or preview the proposal. The modal can be closed by clicking outside it, pressing Escape, or using the close button.

Hamburger Menu

Toggles an active class on the nav container to show/hide links on mobile. Updates aria-expanded for accessibility. The menu closes automatically when a link is clicked or the user taps outside the nav.

`proposal.js` Proposal Page Logic

Powers the interactive experience recipients see when they open a shared proposal link.

URL Parameter Parsing

Reads name and type query parameters via URLSearchParams and dynamically updates the proposal heading (e.g. "Will you be my girlfriend, Sarah") if both values are present.

Yes / No Interaction

Yes hides the proposal state and reveals a celebratory success message.
No deliberately unclikable; moves to a random screen position on mouseenter or touchstart, making it playfully impossible to select.

Keyboard & Navigation

Escape navigates back to the previous page. A Back Home button in the success state redirects to the landing page.

`stories.js` Stories Page Logic

Dynamically renders the stories page from a local data array, simulating a backend data layer.

Mock Data

Stories are stored as an array of objects, each containing couple names, location, image URL, alt text, a quote, and a date.

DOM Rendering

On page load, the script iterates over the stories array and creates an <article> element for each entry using template literals, then appends it to the stories grid. No story content is hardcoded in the HTML.

Logic Flow

Journey	Steps
Proposal Creation	User fills form, `app.js` validates builds URL with query params, modal opens, user shares or previews
Proposal Experience	Recipient opens link, `proposal.js` parses params, heading personalised Yes reveals success state; No escapes cursor
Stories Page	Page loads,`stories.js` reads local array iterates stories, injects article cards into DOM

Edge Case Handling

Edge Case	Handling
Empty form submission	Alert shown; form not submitted
Missing URL parameters	Heading update skipped; default placeholder shown
Web Share API unavailable	Falls back to clipboard copy; uses native prompt as last resort
Modal elements not present	All modal logic guarded with null checks
Stories grid not found	Checks for grid container before populating
No button on touch devices	Evasion triggered on both `mouseenter` and `touchstart`

Reflection

Overall, this was a very interesting project for me, I learnt a lot about collaboration with Git and Github, and even more about standards for writing semantic HTML, and structured design systems with CSS.

That said, collaboration did not come without its challenges, particularly around maintaining a standardized approach to implementing features and pages on the application due to differing perspectives for each collaborator, we were able to overcome this via clear and concise discussions and meetings before and throughout the task delivery processes, where I properly communicated to my partner, and her to me, clear and concise requirements for each week's task.

In a version 2.0, I would work towards improving semantics and optimizing SEO and accessibility for the project to near perfection, as these are the areas we received feedback for improvement.

Contributors

This project was developed collaboratively with;

Oluchi Okwuosa – GitHub

You can view their version of this case study here

Special thanks to Sophia Ahuoyiza - Github for issue submissions and feedback which helped greatly improve this project.

DEV Community: Awoyemi Abiola

Luminary - IWD Project

Introduction

Week 1

Project Setup Phase

My Contributions as Product Lead and Frontend Engineer

Lessons Learned

Week 2

Specific Features Implemented

Technical Implementation Breakdown

BaaS Tool and Integration

Challenges & Resolutions

What I Learned This Week

Week 3

Specific Features Implemented

Technical Implementation Breakdown

BaaS Tool and Integration

Challenges & Resolutions

What I Learned This Week

Week 4 - Final Retrospective

Specific Features Implemented

Technical Implementation Breakdown

Challenges & Resolutions

What I Learned This Week

Sprint Retrospective

A milestone worth celebrating

What went well

What I would do differently

What surprised me

Key technical lessons from the sprint

Shout-outs

Contributors

Github Repository

LovedIn: A Case Study

Introduction

Problem Statement

Solution Design

UI Design System

Colors

Typography

HTML & Structural Approach

Key Semantic Elements Used

CSS Architecture

CSS Variables

Visuals

Responsiveness

JavaScript Implementation

app.js Home Page Logic

Proposal Form Submission

Modal & Sharing

Hamburger Menu

proposal.js Proposal Page Logic

URL Parameter Parsing

Yes / No Interaction

Keyboard & Navigation

stories.js Stories Page Logic

Mock Data

DOM Rendering

Logic Flow

Edge Case Handling

Reflection

Contributors

`app.js` Home Page Logic

`proposal.js` Proposal Page Logic

`stories.js` Stories Page Logic