Badilak Arabi | Professional Frontend Engineering Challenge v1

Prompt

# BADILAK ARABI — FRONTEND DESIGN & ENGINEERING CHALLENGE Act as a senior frontend engineer, UI/UX architect, design-system specialist, and accessibility expert. Build a polished, functional, modern, accessible Arabic RTL frontend prototype for an EXISTING website called **Badilak Arabi**. You cannot inspect the live website, its repository, or screenshots. Use the context below. Never invent existing code structures or claim verified compatibility. ## 1. PROJECT CONTEXT Badilak Arabi is an Arabic-first discovery and decision-support platform, NOT an ecommerce store, generic blog, or SaaS dashboard. It helps users discover Arab-developed products, Arabic-supported services, educational resources, articles, guides, research, and relevant news. Main journey: **Identify a need → Discover options → Understand usefulness and limitations → Read details and sources → Visit the resource.** Distinguish Arab-developed products, services supporting Arabic, and Arabic resources teaching international tools. Never assume complete equivalence with global products. Existing technology: HTML5, CSS3, vanilla JavaScript, modular files, Arabic RTL. No frontend framework. Main sections: - Header, logo, and navigation. - Hero with distinctive Arabic wordmark. - 12 familiar-service shortcuts, including ChatGPT and Canva. - Searchable/filterable product directory. - Product cards with expandable details. - Learning resources and educational channels. - Guides, articles, news, and updates. - Arab-country progress indicators. - Visitor suggestions and corrections. - Reserved advertising previews and disclosures. Existing behaviors include search normalization, filtering, result ordering, load-more, detail views, direct links, browser history, browsing-state restoration, and dynamic service shortcuts. These are PROTECTED existing features. ## 2. PROFESSIONAL DESIGN STANDARDS Apply established design principles, adapted for an Arabic website. Do not imitate other companies' branding or proprietary designs. **Apple Human Interface Guidelines** https://developer.apple.com/design/human-interface-guidelines/ Apply clarity, strong hierarchy, content-first presentation, readable typography, purposeful whitespace, consistent controls, intuitive interactions, clear feedback, and subtle meaningful motion. **Microsoft Fluent 2** https://fluent2.microsoft.design/ Apply systematic spacing, reusable design tokens, consistent component geometry, semantic color roles, restrained elevation, and clear hover/focus/selected/disabled states. **Google Material Design 3** https://m3.material.io/ Apply adaptive layouts, meaningful grouping, understandable component states, accessible touch interactions, and purposeful motion. Avoid copying Android aesthetics. **W3C WCAG 2.2 Level AA** https://www.w3.org/TR/WCAG22/ Target accessible contrast, semantic HTML, keyboard navigation, visible focus, appropriate target sizes, accessible labels, responsive content, and reduced-motion support. Do not claim verified compliance without testing. **Nielsen Norman Group:** Apply progressive disclosure, recognition over recall, reduced cognitive load, clear navigation, and user control. **shadcn/ui philosophy:** Learn from reusable, composable, accessible components. Do not install React, Tailwind, or shadcn/ui. Combine these principles into ONE coherent design system. ## 3. VISUAL IDENTITY Preserve Badilak Arabi's warm, modern, expressive Arabic identity. Current palette: - Deep teal: #123736 - Pale sage: #EDF4EE - Off-white: #FAFBF8 - Bronze: #9B6A3D - Text: #253331 - Muted text: #5D6B65 Existing typography includes Almarai and Cairo. Use clean white cards, subtle shadows, fine borders, restrained decoration, consistent spacing, and approximately 18px card radii where suitable. Maintain a distinctive Arabic character. Avoid generic dashboards, sterile minimalism, excessive gradients, glassmorphism, oversized headings, repetitive cards, and unnecessary animations. Use contemporary editorial UI patterns, elegant microinteractions, balanced density, and responsive composition. Prioritize proven usability over short-lived trends. Do not invent claims about current design popularity. ## 4. IMPLEMENTATION TASKS Build ONE coherent, working prototype demonstrating all four tasks. ### A. NEWS CARDS Create reusable news cards with: - 16:9 representative image. - Arabic headline and excerpt. - Date and optional category. - Clear "اقرأ" link. - Consistent alignment. - Missing-image fallback. - Long-headline handling. - Responsive images and appropriate loading. Layout: 3 columns desktop, 2 tablet, 1 mobile. Use an editorial presentation, not generic database cards. ### B. ARABIC SEARCH & FILTERS Build functional: - Search field. - Category filters. - Selected states. - Clear/reset filters. - Result count. - Empty-results message. - Diacritic and common Alef-variant normalization. - Keyboard-accessible controls. All interactions must work with fictional sample data. ### C. PRODUCT DIRECTORY CARDS Build reusable cards with: - Name and logo fallback. - Practical short description. - Relevant user need. - Important limitation. - Expandable "تفاصيل +" control. - External visit link. - Accessible expanded states. Differentiate primary actions, details, limitations, and informational text. Avoid nested interactive controls. Use fictional sample products; do not invent real-company facts. ### D. RESPONSIVE DESIGN Support 360, 390, 768, 1024, and 1440px widths. Use Grid, Flexbox, CSS logical properties, fluid dimensions, and appropriate breakpoints. Avoid horizontal overflow, overlapping controls, broken Arabic/English mixed text, layout shifts, and unnecessary mobile whitespace. ## 5. INTERACTIONS & ACCESSIBILITY Implement real functional states: Default, hover, focus-visible, selected, expanded/collapsed, disabled where applicable, and empty results. Use lang="ar", dir="rtl", semantic HTML, accessible buttons/links, and ARIA when necessary. Handle mixed-direction strings, English product names, Arabic dates, and numbers. Support prefers-reduced-motion. Keep animations brief and functional, not decorative. ## 6. ZERO-COST IMPLEMENTATION All solutions must use free-to-use technologies and legally reusable assets. - No paid APIs or mandatory subscriptions. - No premium UI kits or paid image libraries. - No required proprietary dependencies. - Prefer native HTML/CSS/JavaScript. - Prefer existing local assets. - Use stable, clear placeholder images in the prototype. - Identify licensing restrictions or possible operational costs. Free implementation does not imply permanently free hosting or maintenance. ## 7. GOOGLE ADSENSE READINESS Design with Google publisher and advertising policies in mind. References: https://support.google.com/adsense/ https://support.google.com/publisherpolicies/ Requirements: - Editorial content remains dominant. - Clearly separate ads from content and navigation. - Avoid misleading CTAs and accidental-click placements. - Avoid intrusive overlays and excessive advertising space. - Preserve existing reserved ad demonstrations and their disclosures. - Do not present previews as active paid ads. - Prevent layout shifts around future advertising placements. - Maintain clear navigation and useful content. - Allow appropriate privacy/consent integration. Never guarantee AdSense approval. Actual compliance depends on production implementation, original content, applicable policies, and Google's review. ## 8. SEO & PERFORMANCE Use semantic heading structure, efficient DOM, responsive images, intrinsic image dimensions, minimal JavaScript overhead, reusable CSS tokens, and component-scoped styling. Consider Core Web Vitals: LCP, CLS, and INP. Avoid unnecessary dependencies, blocking resources, and unstable layouts. Do not modify production canonical URLs, indexing directives, metadata, or structured data. Do not invent performance measurements. ## 9. CRITICAL: PROTECT EXISTING ARCHITECTURE Badilak Arabi is NOT a greenfield project. Any visual improvement must preserve existing functionality. PROTECTED: - Navigation, hash routing, deep links, and direct page access. - Browser Back/Forward behavior. - Search, filters, ordering, and load-more. - Browsing-state and scroll restoration. - Detail views, close/return behavior, and keyboard focus. - Connections between resources, learning, articles, news, and country indicators. - Dynamic service shortcuts and their rotation behavior. - Existing content, labels, country data, sources, and URLs. - Reserved advertising demonstrations and commercial disclosures. - Current branding and established design decisions. TECHNICAL SAFETY: - Never replace existing routing or state management. - Never rebuild unrelated application logic. - Avoid broad CSS overrides and global selectors. - Avoid JavaScript namespace collisions. - Prevent duplicate event listeners. - Scope new CSS/JS to individual components. - Avoid changing existing DOM contracts without inspection. - Prefer isolated, reusable components and progressive enhancement. - Do not introduce unnecessary dependencies. Because you cannot inspect the actual repository, your output is a PROTOTYPE, NOT a verified production patch. For future integration, require: 1. Inspect relevant source files and dependencies. 2. Identify existing interfaces and protected behavior. 3. Implement the smallest necessary change. 4. Work in an isolated development branch. 5. Review code differences and unintended semantic changes. 6. Test affected user journeys and responsive behavior. 7. Verify history, state restoration, filters, links, and focus behavior. 8. Document rollback steps. Preservation of working functionality takes priority over visual novelty. ## 10. DELIVERABLES **A. Working code** Provide ONE self-contained runnable HTML file with embedded CSS and vanilla JavaScript demonstrating the four tasks together. Use a small fictional sample dataset. Every demonstrated control must work. Avoid fake functional buttons. **B. Design system** Use reusable CSS variables for colors, spacing, typography, borders, radii, shadows, and interaction states. **C. Brief engineering notes** Explain: - Key Apple/Fluent/Material/WCAG decisions. - Component structure and reusable styles. - Arabic RTL and accessibility handling. - Performance and licensing considerations. - Assumptions needing repository inspection. **D. Regression Risk & Integration Report** Briefly identify: - Potentially affected components. - Protected existing features. - CSS/JavaScript conflict risks. - Integration requirements. - Regression checks. - Rollback approach. **E. Acceptance checks** Include practical checks for responsive layout, Arabic search, filters, expandable details, keyboard navigation, RTL, browser history, deep links, browsing state, ad separation, and performance. Distinguish performed tests from recommended tests. ## 11. PRIORITIES & OUTPUT RULES Prioritize: 1. Functional correctness. 2. Existing architecture protection. 3. Professional visual quality. 4. Arabic RTL and accessibility. 5. Responsive design. 6. Maintainability and performance. 7. Zero-cost and legal asset use. 8. AdSense policy readiness. 9. Modern aesthetics. Deliver executable code, not just design advice. Do not fabricate existing selectors, repository structures, browser tests, verified compatibility, measured performance, WCAG compliance, AdSense approval, or licensing permissions. Keep explanations concise and prioritize complete code. If output limits are restrictive, simplify decorative details and sample data while preserving essential functionality. Disclose anything incomplete. **FINAL GOAL: Produce an elegant, functional, free, modern Arabic RTL frontend prototype demonstrating professional design principles while explicitly protecting the existing Badilak Arabi architecture and user journeys.**

A system prompt was added to support web rendering