Software Engineering Project — Website Reconstruction (2026)

Evaluation and grading

  • The course instructor is solely responsible for grading and for defining the grading rubric. The project sponsor (Process Feedback) will provide formative feedback focused on real-world software engineering and web development practices, but will not assign grades.

  • You own your source code and it need not be shared with us. Repository history and workflow conventions will also be evaluated by your instructor.

  • Use of AI or generative tools is permitted, subject to the course’s AI policy. Regardless of tooling, submitted work must demonstrate: readable and maintainable code structure, consistent formatting, and clear documentation.

Document stability and updates

This project specification may be updated during the semester to correct minor errors, clarify requirements, or improve wording. Such updates will not change the overall structure of the project, its core objectives, or major expectations.

Any substantive changes, if required, will be communicated clearly by the instructor.

1. Background

The Process Feedback public-facing website (distinct from the application itself) has historically been maintained using WordPress with Elementor-based page design. While this approach enabled rapid early development, it presents limitations as the website grows in complexity and scale.

Key limitations of the current workflow include:

  • Difficulty maintaining precise visual consistency across pages.
  • Limited support for structured, reusable content (e.g., maintaining FAQs or shared sections across multiple pages).
  • Reduced effectiveness of modern development tools for quality assurance, such as global typo detection, refactoring, or content validation using code editors and automated tooling.
  • Constraints on integrating contemporary frontend workflows that support modularity, versioning, and programmatic content rendering.

Modern web development practices increasingly rely on code-based systems that separate content, structure, and presentation. This project is designed to give students hands-on experience with such practices while working with a realistic, production-grade reference website.

2. Objective

The objective of this project is to reconstruct selected pages of an existing public-facing website using modern web technologies, while achieving pixel-level fidelity with the original design and interaction patterns.

Students will build a new website that visually and behaviorally matches the public website available at https://processfeedback.org.

Minimum required pages

You must reconstruct at least the following pages:

1. The landing page (/)

Mandatory components:

  • Navigation Bar & responsive hamburger menu for smaller screen sizes
  • Hero Section
  • Footer
  • Any three (3) additional sections of your choice from the landing page (listed below):
    • “What is Process Feedback” section
    • “Our Tools” section: Teachers and Students
    • “Features Loved” section: Teachers and Students
    • “Academic Conferences” section
    • “Teacher Trainings” section
    • “We simply reveal the writing process data” section
    • “Frequently Asked Questions” section
    • “Used In 100+ Countries” section
    • “See It in Action” section

2. The contact page (/contact)

3. Any three additional pages from the website. Policy pages (e.g., privacy policy) are allowed.

The expectation of an “exact match” includes:

  • Layout and spacing
  • Typography (font families, font sizes, line height)
  • Color palette and visual hierarchy
  • Animations, transitions, and hover states
  • Navigation behavior and interaction patterns

3. Choice of technology

There are no restrictions on the choice of technology.

You may use any contemporary web development stack, including but not limited to:

The selected technology must allow you to meet the requirements specified in this document.

4. Branding, attribution, and disclosure (non-negotiable)

Because this project will be hosted online, it must not misrepresent itself as the real Process Feedback website.

4.1 Branding restrictions

All of the following requirements must be met:

  • The website must not present itself as the official Process Feedback website.

  • The Process Feedback logo must not be used.

  • A custom project logo must be created.

  • The hero heading text “Process First. AI Second.” must be replaced with: “Course Project at UMSL”

  • The hero subtitle must explicitly disclose duplication, for example:

    “This project is a duplicate of a real public website created solely for academic purposes. The original website is available at processfeedback.org.”

4.2 Mandatory content attribution

Students may copy text and images from the original website only if attribution is provided clearly and repeatedly.

The phrase “Content from processfeedback.org” must appear in all of the following locations:

  1. The landing page footer
  2. The footer of every required page (or a global footer)
  3. The project README file
  4. A dedicated attribution page linked from the footer

Failure to meet attribution requirements constitutes a violation of project constraints.

5. Search engine and visibility restrictions (non-negotiable)

To prevent interference with the original website’s traffic or search ranking, the project website must not be indexed by search engines.

5.1 Required no-index configuration

You must implement both of the following:

  1. A robots.txt file that disallows all crawling.
  2. A <meta name="robots" content="noindex, nofollow"> tag on every page.

5.2 Password protection (optional)

Password protection is permitted but not required. If implemented, access credentials must be shared with the instructor and sponsor.

6. Hosting and submission requirements

  • The project website must be hosted online and accessible through a standard web browser.
  • Password protection is acceptable.
  • A public URL must be available.

Hosting choices, repository structure, and workflow conventions are governed by course requirements and evaluated at the instructor’s discretion.

7. Phase I expectations (before midterm)

7.1 Visual and interaction fidelity

  • The website must match the reference site exactly in visual appearance and behavior.
  • Navigation menus, hover interactions, animations, and transitions must behave identically.
  • The navigation bar and footer must visually and behaviorally match the original site.

7.3 Responsiveness

  • Pages must render correctly on mobile phones, tablets, and desktop screens.
  • Layout must adapt appropriately across common screen sizes and browsers.

7.4 Error handling

  • A functional 404 page must be implemented and displayed for invalid routes.

7.5 Console behavior

  • The website must not produce critical console errors during normal use.
  • Any non-critical warnings must be understood and documented if present.

7.6 Accessibility (baseline expectations)

Formal WCAG 2.1 conformance evaluation is deferred to Phase II. However, at minimum, the following accessibility practices must be followed:

  • Proper use of semantic HTML elements
  • Logical heading structure
  • Meaningful alternative text for images
  • Form inputs with associated labels
  • Keyboard-accessible navigation for primary interactions

7.7 Printing behavior

When a user prints a page (e.g., via Ctrl/Cmd + P):

  • Headings and body text must remain readable
  • Content should not be clipped or overlap
  • Printed output should preserve logical structure
  • Navigation elements may be hidden if appropriate

7.8 Basic performance

Advanced performance optimization is not required in Phase I. However, students are expected to avoid obvious performance issues.

Performance may be evaluated using PageSpeed Insights.

7.9 Explicit exclusions

The goal of the project is faithful reproduction of visible structure, content, and interaction behavior. Students are not required to reproduce:

  • Analytics, tracking, or advertising scripts used on the original website
  • Backend services or infrastructure used by the original site
  • Known bugs or technical issues present on the reference website

8. Contact page functional requirements

The contact page must be fully functional. At a minimum:

  • The form must validate user input.
  • Upon submission, the form must send an email notification to a designated recipient (e.g., a project team email address).
  • Users must receive clear success or failure feedback.

Basic security expectations include:

  • Server-side validation
  • At least one spam-prevention mechanism (e.g., honeypot, rate limiting, or human verification)
  • No exposure of private keys or credentials in frontend code

9. Phase II expectations (final poster/presentation)

9.1 Feedback incorporation

All substantive feedback from Phase I must be addressed.

9.2 Accessibility verification (WCAG 2.1 AA)

Documentation of findings and fixes must be included. In Phase II, students must evaluate accessibility using:

  • An automated accessibility audit tool such as Lighthouse
  • Manual keyboard navigation testing

9.3 Proposed and implemented enhancement

Students must propose and implement at least one meaningful improvement, such as:

  • Dark mode support
  • Improved information architecture or content organization
  • Enhanced performance strategies
  • More robust human verification for forms

The proposal and implementation rationale must be documented.

10. Recognition and distinction

Exceptional project work may be formally recognized by the project sponsor. Two forms of recognition may be awarded:

  1. Midterm recognition. One project team may receive a Project Sponsor Recognition for Technical Fidelity for demonstrating exceptional precision in visual fidelity, interaction accuracy, and technical execution during Phase I of the project.

  2. Final recognition. One project team may receive a Project Sponsor Recognition for Outstanding Project Execution for demonstrating overall excellence in the final submission, including responsiveness to feedback, technical rigor, and thoughtful implementation of enhancements beyond baseline requirements.

Recognition will be documented through an official letter issued by the project sponsor. These recognitions are honorary and do not affect course grades, which are determined solely by the course instructor.

Recognition is competitive and discretionary. Not all semesters are guaranteed to result in an award.

11. Testing and review

The instructor will conduct testing using standard evaluation methods, which may include:

  • Viewing the site on multiple devices and browsers
  • Testing responsiveness and navigation
  • Submitting the contact form
  • Inspecting printed output
  • Reviewing accessibility behavior

12. Code Ownership

Students retain full ownership of their code. During presentations or demonstrations, students may be asked to explain design and implementation decisions.

We are still working on a short course for students. Please stay tuned!