BUILD WEB, GUIDE AI Business Web Development with AI By Michael Borck ============================================================ ============================================================ SOURCE: index.qmd ============================================================ # Preface ## Why This Book Exists Most web development books teach you technologies. This one teaches you to think like a professional developer who happens to use specific technologies. That distinction matters because AI can write HTML, CSS, and JavaScript faster than you ever will. If your only skill is writing markup and code, you are competing with something that does not sleep. But if you can translate a business need into a technical requirement, evaluate whether a WordPress site or a React app is the right call, and explain your reasoning to a non-technical stakeholder — you have the skills that actually matter. This book grew out of teaching business web and mobile technologies to students who were not computer science majors. They needed to build real things for real purposes, and they needed to understand enough about the technology to make professional decisions — not just follow tutorials. The exercises, case studies, and projects in these pages were tested in classrooms before they were written up. ## Who This Book Is For - Students in business technology or web development courses - Career changers entering tech from business backgrounds - Professionals who need to understand web development for their roles - Anyone who wants to build web solutions with AI assistance No prior programming experience required. We start from scratch. ## What This Book Is Not This is not a computer science textbook. It does not cover algorithms, data structures, or computational theory. It teaches you to build things for the web, with enough understanding to make good decisions about how. It is not a framework-of-the-month guide. You will learn HTML, CSS, JavaScript, WordPress, and React — technologies chosen because they cover the spectrum from simple to complex and will remain relevant regardless of what is trending next year. It is not a book that treats AI as a novelty. AI is your development partner throughout. The book teaches you to architect solutions that AI helps you build, evaluate AI output with professional judgement, and communicate requirements clearly enough for AI to be useful. And it is not a book for people who want to become full-time frontend engineers. It is for people who want to understand web development well enough to lead projects, evaluate vendors, build prototypes, and make informed technology decisions in a business context. ## If You Are Feeling Uncertain You do not need to be "technical" to build for the web. That word gets used as a gatekeeper, but the reality is that web development is a learnable skill, not a personality trait. If you can write a clear email, you can learn to write a clear prompt. If you can organise a spreadsheet, you can learn to structure a web page. This book starts where you are. ## How This Book Is Structured The book progresses from foundations to full applications: Part 0 introduces your AI development partnership — how to work with AI effectively from day one. Part 1 covers web fundamentals: HTML structure, CSS presentation, JavaScript behaviour. You understand the building blocks before assembling them. Part 2 moves to platforms: WordPress for rapid development, content management, and extending with plugins and themes. Part 3 introduces React for component-based applications, headless architecture, and modern development patterns. Part 4 ties it all together: professional practices, emerging technologies, and building a development career. Each chapter follows a consistent pattern: concept first, AI exploration, hands-on practice, business connection, reflection. ## The Companion Books The methodology in this book draws on Conversation, Not Delegation: How to Think With AI, Not Just Use It, which covers the full framework for working with AI across any discipline. If you are also interested in Python development, the Python learning path (Think Python, Direct AI → Code Python, Consult AI → Ship Python, Orchestrate AI) applies the same methodology to programming. All titles are available at books.borck.education. ## Ways to Engage with This Book This book is available in several formats. Pick whichever fits how you work and learn. - Read it online. The full book is freely available at the companion website, with dark mode, search, and navigation. - Read it on paper or e-reader. Available as a paperback and ebook through Amazon KDP. - Converse with it. The online edition includes a chatbot grounded in the book's content. - Feed it to your own AI. The `llm.txt` file provides a clean text version of the entire book, ready to paste into ChatGPT, Claude, or any AI tool. - Run the code. All code examples and project files are available on GitHub. DeepWiki provides an AI-navigable view of the repository. - Browse all books. This book is part of a series. See all titles at books.borck.education. The online version is always the most current. ## Source Code & Feedback All code examples and project files are available at: https://github.com/michael-borck/build-web-guide-ai Found an error? Have a suggestion? - Open an issue: https://github.com/michael-borck/build-web-guide-ai/issues - Email: michael@borck.me ============================================================ SOURCE: copyright.qmd ============================================================ # Copyright \thispagestyle{empty} Build Web, Guide AI: Business Web Development with AI Copyright 2026 Michael Borck. All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the author, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law. First Edition, 2026 While every precaution has been taken in the preparation of this book, the author assumes no responsibility for errors or omissions, or for damages resulting from the use of information contained herein. --- Cover Art Created using AI image generation, with prompts crafted by the author depicting the themes of web development and human-AI collaboration. Production Notes This book was written in Markdown using Quarto. The text is set in system fonts optimised for screen and print reading. Code examples use a monospace font for clarity. Editorial assistance provided by Claude (Anthropic). The author reviewed and approved all content. --- Online Edition A free online version of this book is available at: https://michael-borck.github.io/build-web-guide-ai --- michael@borck.me \newpage ============================================================ SOURCE: chapters/reading-list.qmd ============================================================ # Weekly Reading List This reading list accompanies the 12-week course structure, combining chapters from this book, methodology from Intentional Prompting, and curated external resources. ## How to Use This List Each week includes: - Book Chapter: Primary reading from this book - Methodology: Relevant chapter from Intentional Prompting - Essential Reading: Must-read external resources - Deeper Dive: Optional additional resources for those wanting more ## Reading Strategy Read the book chapter first to understand concepts, then explore external resources for different perspectives and official documentation. --- ## Week 1: Foundations & AI Partnership ### Focus Setting up your development environment and establishing your AI partnership approach. ### Book Chapters - Chapter 0: Understanding Your AI Web Development Partner ### Intentional Prompting - Chapter 1: Introduction - Chapter 3: Intentional Prompting Principles ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | MDN | Getting started with the web | MDN: Getting Started | | web.dev | How the web works | web.dev: How the web works | | W3Schools | Introduction to HTML | W3Schools: HTML Introduction | ### Deeper Dive - History of the Web - W3C - How browsers work - Google Chrome Blog --- ## Week 2: HTML Structure ### Focus Semantic HTML and document structure as information architecture. ### Book Chapters - Chapter 1: Structure: HTML as Information Architecture ### Intentional Prompting - Chapter 4: The Six-Step Methodology (overview) - Chapter 5: Restate and Identify ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | MDN | HTML basics | MDN: HTML Basics | | MDN | Document structure | MDN: Document Structure | | web.dev | Semantic HTML | web.dev: Semantic HTML | | W3Schools | HTML Elements | W3Schools: HTML Elements | ### Deeper Dive - HTML Living Standard - WHATWG (reference) - HTML Best Practices - Community guide --- ## Week 3: CSS Presentation ### Focus Visual design, responsive layouts, and mobile-first development. ### Book Chapters - Chapter 2: Presentation: CSS as Visual Communication ### Intentional Prompting - Chapter 6: Work by Hand - Chapter 7: Pseudocode ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | MDN | CSS basics | MDN: CSS Basics | | MDN | CSS layout | MDN: CSS Layout | | web.dev | Learn CSS | web.dev: Learn CSS | | web.dev | Responsive design | web.dev: Responsive Design | | W3Schools | CSS Introduction | W3Schools: CSS | ### Deeper Dive - CSS Tricks: A Complete Guide to Flexbox - CSS Tricks: A Complete Guide to Grid - Every Layout - Layout patterns --- ## Week 4: JavaScript Behaviour ### Focus Adding interactivity, DOM manipulation, and event handling. ### Book Chapters - Chapter 3: Behaviour: JavaScript as User Interaction ### Intentional Prompting - Chapter 8: Convert to Code - Chapter 11: Debugging with AI ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | MDN | JavaScript basics | MDN: JavaScript Basics | | MDN | DOM Introduction | MDN: DOM Introduction | | MDN | Events | MDN: Introduction to Events | | javascript.info | The Modern JavaScript Tutorial | javascript.info | | W3Schools | JavaScript Tutorial | W3Schools: JavaScript | ### Deeper Dive - Eloquent JavaScript - Free online book - You Don't Know JS - Deep dive series --- ## Week 5: APIs & Data ### Focus Connecting to external services, fetching data, and working with JSON. ### Book Chapters - Chapter 4: Connection: APIs as Business Integration ### Intentional Prompting - Chapter 9: Test with Data - Chapter 10: Intentional Prompting Patterns ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | MDN | Fetching data | MDN: Fetching Data | | MDN | Working with JSON | MDN: Working with JSON | | MDN | Async JavaScript | MDN: Asynchronous JavaScript | | web.dev | Introduction to fetch | web.dev: Fetch API | ### Deeper Dive - REST API Tutorial - REST concepts - JSONPlaceholder - Practice API - Public APIs List - APIs to explore --- ## Week 6: Portfolio Project & Accessibility ### Focus Completing Assessment 1, accessibility fundamentals, and project review. ### Book Chapters - Project: Portfolio Website - Review Chapters 1-4 ### Intentional Prompting - Chapter 12: Refactoring Strategies ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | web.dev | Learn Accessibility | web.dev: Learn Accessibility | | MDN | Accessibility | MDN: Accessibility | | W3C | WCAG Quick Reference | WCAG 2.1 Quick Ref | | WebAIM | Introduction to Accessibility | WebAIM: Introduction | ### Deeper Dive - A11y Project Checklist - Inclusive Components - Accessible patterns --- ## Week 7: Content Management Systems ### Focus Understanding CMS value proposition and WordPress as a platform. ### Book Chapters - Chapter 5: Why CMS? The Business Value of Managed Content - Chapter 6: WordPress as Platform ### Intentional Prompting - Chapter 13: Case Studies (approach to complex projects) ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | WordPress.org | Getting Started | WordPress: Getting Started | | WordPress.org | WordPress Features | WordPress: Features | | W3Techs | CMS Usage Statistics | W3Techs: CMS | | WPBeginner | WordPress Guide | WPBeginner: Guide | ### Deeper Dive - WordPress Developer Resources - WordPress TV - Video tutorials --- ## Week 8: Extending WordPress ### Focus Plugins, themes, and customisation strategies. ### Book Chapters - Chapter 7: Extending Platforms ### Intentional Prompting - Chapter 14: Scaling Complexity ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | WordPress.org | Theme Handbook | Theme Handbook | | WordPress.org | Plugin Handbook | Plugin Handbook | | WordPress.org | Child Themes | Child Themes | | WPBeginner | Must Have Plugins | Essential Plugins | ### Deeper Dive - WordPress Coding Standards - Theme Unit Test --- ## Week 9: Tuition-Free Week ### Focus Self-directed learning and project catch-up. ### Suggested Activities - Review previous chapters - Complete any outstanding exercises - Explore Intentional Prompting deeper - Experiment with WordPress customisation ### Optional Reading | Resource | Topic | Link | |----------|-------|------| | Smashing Magazine | WordPress Articles | Smashing: WordPress | | CSS Tricks | Various | CSS Tricks | | Dev.to | Web Development | Dev.to | --- ## Week 10: WordPress REST API ### Focus Headless architecture and API-first thinking. ### Book Chapters - Chapter 8: Headless Architecture ### Intentional Prompting - Review Chapter 8-9: Convert to Code, Test with Data ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | WordPress.org | REST API Handbook | REST API Handbook | | WordPress.org | REST API Reference | REST API Reference | | CSS Tricks | WP REST API | CSS Tricks: WP REST | ### Deeper Dive - Postman - API testing tool - WP REST API Demo --- ## Week 11: React Integration ### Focus Component-based thinking and connecting React to WordPress. ### Book Chapters - Chapter 9: Component Thinking: React ### Intentional Prompting - Chapter 12: Refactoring Strategies (component extraction) ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | React.dev | Quick Start | React: Quick Start | | React.dev | Thinking in React | Thinking in React | | React.dev | Tutorial | React Tutorial | | MDN | React Getting Started | MDN: React | ### Deeper Dive - React Patterns - React TypeScript Cheatsheet --- ## Week 12: Frameworks & Professional Practice ### Focus CSS frameworks, code quality, and professional development practices. ### Book Chapters - Chapter 10: Rapid Development: CSS Frameworks - Chapter 11: Professional Practices ### Intentional Prompting - Chapter 15: Teaching and Learning (reflection) ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | Bootstrap | Getting Started | Bootstrap Docs | | Tailwind CSS | Getting Started | Tailwind Docs | | Git | Git Handbook | GitHub: Git Handbook | | web.dev | Testing | web.dev: Testing | ### Deeper Dive - Atlassian Git Tutorials - Testing Library --- ## Week 13: Future & Career ### Focus Emerging technologies, portfolio building, and career positioning. ### Book Chapters - Chapter 12: Evaluating Emerging Technologies - Chapter 13: Your Development Career - Chapter 14: The AI-Era Developer - Project: React Integration (final submission) ### Intentional Prompting - Chapter 16: Future Directions ### Essential Reading | Resource | Topic | Link | |----------|-------|------| | web.dev | Web Vitals | web.dev: Web Vitals | | web.dev | PWA | web.dev: Learn PWA | | State of JS | Survey Results | State of JS | | State of CSS | Survey Results | State of CSS | ### Deeper Dive - Roadmap.sh - Developer roadmaps - The Pragmatic Engineer - Career insights - Josh W Comeau's Blog - Modern CSS/React --- ## Quick Reference: External Resources ### Official Documentation | Resource | Best For | URL | |----------|----------|-----| | MDN Web Docs | Comprehensive reference | developer.mozilla.org | | web.dev | Modern best practices | web.dev | | W3Schools | Quick examples | w3schools.com | | WordPress.org | WordPress reference | wordpress.org | | React.dev | React documentation | react.dev | ### Learning Platforms | Resource | Type | URL | |----------|------|-----| | freeCodeCamp | Interactive tutorials | freecodecamp.org | | Codecademy | Interactive courses | codecademy.com | | Scrimba | Video + coding | scrimba.com | | Frontend Masters | Video courses (paid) | frontendmasters.com | ### Community & News | Resource | Type | URL | |----------|------|-----| | Dev.to | Articles & community | dev.to | | CSS Tricks | CSS & frontend | css-tricks.com | | Smashing Magazine | Web design & dev | smashingmagazine.com | | Hacker News | Tech news | news.ycombinator.com | ### Tools | Tool | Purpose | URL | |------|---------|-----| | Can I Use | Browser compatibility | caniuse.com | | CodePen | Code playground | codepen.io | | GitHub | Code hosting | github.com | | Lighthouse | Performance testing | Built into Chrome DevTools | --- ## Reading Tips 1. Don't read everything - Focus on Essential Reading first 2. Hands-on over theory - Try examples as you read 3. MDN is your friend - Best for accurate, detailed explanations 4. web.dev for modern practices - Google's recommendations 5. W3Schools for quick reference - Fast examples, less depth 6. Use AI to explain - If an article is confusing, ask AI to explain it differently ============================================================ SOURCE: acknowledgments.qmd ============================================================ # Acknowledgments This book grew out of teaching business web and mobile technologies to students who were not computer science majors but needed to build real things for real purposes. The exercises, case studies, and projects in these pages were tested in classrooms, and the students who worked through them shaped every chapter. Their questions — especially the ones that started with "but why would I..." — kept the book focused on what actually matters in a business context. Colleagues in business and information systems provided the cross-disciplinary perspective that kept the technical content grounded in professional reality. The book is better for every conversation about what employers actually need graduates to know. The web development community's commitment to open documentation — MDN Web Docs, the WordPress documentation, the React documentation — makes resources like this possible. The open source community behind Quarto, GitHub, and GitHub Pages made it possible to write, build, and publish across multiple formats without a traditional publisher. AI tools were used throughout the writing process. Claude (Anthropic) served as a conversation partner for drafting, iterating, and refining. The process was the same one the book teaches: guide the AI, evaluate its output, and maintain professional judgement throughout. Every chapter reflects the author's decisions. The AI made the work faster. It did not make the decisions. ============================================================ SOURCE: chapters/chapter-ai-web-partner.qmd ============================================================ # Understanding Your AI Web Development Partner ## A New Way to Build for the Web Right now, AI can write HTML, CSS, and JavaScript in seconds. It can create entire websites, debug code, and explain complex concepts. So why learn web development at all? Here's the truth: AI is incredible at writing code, but it doesn't understand what your business needs. You're the architect, the translator between business requirements and technical solutions. AI is your highly skilled assistant who needs clear direction. This book teaches you to be that architect. ## The Partnership Experiment Let's discover how AI really works as a web development partner. This experiment will shape how you learn throughout this book. ### Round 1: The Vague Request Open your AI assistant (ChatGPT, Claude, or whatever you're using). Type this exactly: What did you get? The AI probably asked questions or made assumptions. This is your first lesson: AI needs direction. ### Round 2: The Simple Request Now try: You likely got a massive amount of HTML, CSS, maybe JavaScript – a complete but generic template. This is AI's default: give you everything at once. ### Round 3: The Learning Request Now try: You might get: Much clearer! AI responds to your learning needs when you express them clearly. ### Round 4: The Concept Request Finally, try: Now you're using AI to build understanding, not just generate code. ## What This Experiment Teaches Us 1. AI defaults to complexity – It assumes you want a "complete" solution 2. Your prompts shape your learning – Clear learning goals get clearer responses 3. Concepts before code – You can use AI to understand ideas before syntax 4. You're in control – AI follows your lead, not the other way around ## The Three Learning Strategies Throughout this book, we'll follow three core strategies: ### Strategy 1: Understand the Concept Before the Code Every web development task follows patterns. Understand the pattern first, then learn how HTML/CSS/JavaScript expresses it. Example: Don't ask "How do I make a navigation menu?" Instead, ask "What is the purpose of navigation on a website?" Then, "Show me the simplest HTML navigation." ### Strategy 2: Use AI to Explore, Not to Avoid Learning AI is your exploration tool. Use it to: - See different approaches to the same problem - Understand why code works - Compare technologies - Debug your understanding ### Strategy 3: Build Mental Models, Not Just Working Websites A working website isn't the goal. Understanding how and why it works is. Use AI to build these mental models. Example: Ask "Draw a diagram showing how HTML, CSS, and JavaScript work together" or "Explain responsive design using a newspaper analogy." ## How AI Thinks vs How Developers Think ### AI Thinks in Patterns - It has seen millions of websites - It pattern-matches to give you a "typical" solution - It doesn't understand your specific business context - It can't know what you don't know yet ### Developers Think in Problems - What exactly needs to be solved? - Who is the user? - What's the simplest solution? - How will this be maintained? - What could go wrong? Your job is to bridge this gap: Think like a developer, then guide AI to help you implement. ## Your Progressive AI Journey ### Part I (Chapters 1-4): AI as Concept Explorer ### Part II (Chapters 5-8): AI as Implementation Assistant ### Part III (Chapters 9-11): AI as Code Producer ### Part IV (Chapters 12-14): AI as Strategic Advisor ## The Honest Truth By the end of this book: - AI will still write code faster than you ✓ - But you'll know what to ask for ✓ - You'll understand what it gives you ✓ - You'll fix it when it's wrong ✓ - You'll explain it to stakeholders ✓ - You'll be the architect, not the typist ✓ This is not a consolation prize. This is the actual job of a modern web developer. ## Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 0.1: Prompt Evolution (Level 1) Start with "website" and evolve your prompt through 4 iterations to get the simplest possible "About Us" page. Document each iteration and what changed. ### Exercise 0.2: Concept Extraction (Level 2) Ask AI to explain "responsive design" three different ways: 1. Using a technical explanation 2. Using a real-world analogy 3. Using a business justification Which helped you understand best? Why? ### Exercise 0.3: AI Comparison (Level 3) Ask the same question to two different AI tools (or the same tool twice). Compare the responses. What's consistent? What differs? What does this tell you about using AI? ### Exercise 0.4: Business Translation (Level 4) A client says: "I want a website that looks professional and works on phones." Write three different AI prompts that would help you: 1. Clarify what "professional" means 2. Understand their mobile requirements 3. Explore technology options ### Exercise 0.5: AI Learning Plan (Level 5) Design your personal AI learning strategy for this book: 1. What kinds of prompts will you start with? 2. How will you verify AI's answers? 3. What questions will you ask to deepen understanding? 4. How will you track what you've learned? Create a "My AI Partnership Plan" document. ## Chapter Summary - AI is your learning partner, not your replacement - Clear prompts lead to clear learning - Understanding concepts matters more than memorising syntax - You're learning to be an architect who uses AI as a tool - Business context shapes everything in web development ## Reflection Before moving to Chapter 1, ensure you: - [ ] Completed the Partnership Experiment - [ ] Understand why AI overcomplicates by default - [ ] Can evolve prompts from vague to learning-focused - [ ] See yourself as an architect, not a code typist - [ ] Have a plan for using AI as a learning partner ## Your Learning Journal Start your learning journal now. For this chapter, record: 1. Partnership Experiment Results: What surprised you about AI's responses? 2. Best Prompt: Which prompt got you the most useful response? 3. Mental Model: How do you now think about AI as a development partner? 4. Business Question: What kind of web solutions do you want to build? ## Related Materials This book is part of a comprehensive series for mastering modern software development in the AI era: Foundational Methodology - Converse Python, Partner AI: The Python Edition Python Track - Think Python, Direct AI: Computational Thinking for Beginners - Perfect for absolute beginners - Code Python, Consult AI: Python Fundamentals for the AI Era - Core Python knowledge - Ship Python, Orchestrate AI - Professional Python in the AI Era Web Track - Build Web, Guide AI: Business Web Development with AI (this book) - HTML, CSS, JavaScript, WordPress, React ## Next Steps In Chapter 1, we'll explore how web pages are structured using HTML. You'll use your new prompt skills to discover semantic markup – the foundation of everything we build. We'll start with the concept of "documents as structured information" before writing a single line of code. Remember: You're not learning to code. You're learning to think like a web professional who directs AI to help build solutions. Let's begin! ============================================================ SOURCE: chapters/chapter-structure.qmd ============================================================ # Structure: HTML as Information Architecture ## The Concept First Before we write any HTML, let's understand what we're really doing: organising information so both humans and machines can understand it. Every document you've ever read has structure. A book has chapters, sections, and paragraphs. A business report has headings, bullet points, and tables. A restaurant menu has categories, items, and descriptions. This structure isn't decoration—it's how we communicate meaning. HTML (HyperText Markup Language) is simply the language we use to describe document structure for the web. When you write HTML, you're not designing how something looks—you're declaring what something is. This distinction matters enormously. A heading isn't big, bold text. A heading is a heading—a structural element that indicates hierarchy and importance. How it appears is a separate concern entirely. ## Understanding Through Architecture Think of a well-designed building: - The foundation supports everything above it - Walls and rooms divide space into meaningful areas - Signs and labels tell you what each area is for - Doors and corridors connect different spaces - Building codes ensure safety and accessibility Now think about a web page: - The document declaration establishes what kind of document this is - Semantic elements divide content into meaningful sections - Tags label what each piece of content represents - Links connect pages and resources - Web standards ensure accessibility across devices The parallel is precise. An architect doesn't just make a building that stands—they create spaces that people can navigate, understand, and use. A web developer doesn't just make a page that displays—they create documents that humans can read and machines can process. ## The Architecture Mindset When you look at any web page, train yourself to see structure first, appearance second. Ask: "What are the meaningful sections here? How is the content organised? What is each element's purpose?" ## Discovering Structure with Your AI Partner Let's use AI to explore these concepts before we see any code. Remember from Chapter 0: we're using AI to build understanding, not to avoid learning. ### Exploration 1: Document Anatomy Before we think about HTML at all, let's think about documents: Notice what your AI identifies: categories of food, individual items, descriptions, prices, perhaps special callouts for dietary information. This is structure—pure information architecture that exists independent of how it's presented. Now follow up: The specific content differs, but structural patterns repeat. Headings introduce sections. Paragraphs contain flowing text. Lists group related items. This pattern recognition is the foundation of HTML thinking. ### Exploration 2: Semantic Meaning The word "semantic" means "relating to meaning." Semantic HTML uses elements that describe what content is, not how it should look. This conversation should reveal why meaningful labels matter. A library where books are only identified by shelf location would be nearly useless. Similarly, a web page where content is only identified by its visual appearance loses meaning for search engines, screen readers, and future maintainers. Follow up: ### Exploration 3: The Simplest Valid Page Now let's see actual HTML, but the simplest possible version: Your AI should give you something like: Don't just accept this—have a conversation about it: These conversations build understanding that copying code never provides. ## From Concept to Code Let's build your HTML understanding progressively, starting from the absolute basics. ### The Document Container Every HTML page starts with a declaration and a container: The `` tells browsers "this is a modern HTML document." The `` element is the root container for everything else. The `lang` attribute declares the language—essential for screen readers and translation tools. ### The Two Main Sections Inside the HTML container, every page has exactly two sections: The `` contains metadata—information about the page that doesn't appear on screen. The `` contains the actual content visitors see and interact with. Think of it like a business letter: the `` is the envelope with addresses and stamps, while the `` is the letter inside. ### Semantic Content Elements Now let's add meaningful content. HTML provides elements that describe what content is: Notice what we've communicated: - `` — the introductory content for the page - `` — the primary content (there should only be one) - `` — distinct, thematically grouped content - `` — closing information - ``, `` — heading hierarchy (h1 is most important) - `` — paragraphs of text A screen reader can now navigate this page by headings. Search engines understand what's primary content versus footer material. Future developers can immediately grasp the page structure. ### Common Semantic Elements Here are the structural elements you'll use most often: | Element | Purpose | Example Use | |---------|---------|-------------| | `` | Introductory content | Site branding, navigation | | `` | Navigation links | Main menu, breadcrumbs | | `` | Primary page content | The "meat" of the page | | `` | Thematic grouping | Chapters, tabbed content | | `` | Self-contained content | Blog post, news story | | `` | Related but separate | Sidebar, pull quote | | `` | Closing content | Copyright, contact links | ## Common Mistake Don't choose elements based on how they look by default. Choose them based on what the content is. A `` isn't "a box"—it's a thematic grouping of content. Appearance is CSS's job (Chapter 2). ### Headings Create Hierarchy Headings aren't just "big text"—they create a document outline: This hierarchy should make sense as an outline. Don't skip levels (no jumping from h2 to h4) and don't use headings just to make text bigger. ## Building Your Mental Model ### The Tree Structure HTML forms a tree, like a family tree or organisation chart: Elements contain other elements. This nesting creates relationships: the `` belongs to its ``, which belongs to ``, which belongs to ``. ### Tags, Elements, and Attributes Let's clarify terminology: - Tag: `` is the opening tag, `` is the closing tag - Element: The complete unit from opening to closing tag, including content - Attribute: `href="about.html"` provides additional information - Content: "About Us" is the text content between tags ### The Box Model Preview Every HTML element creates an invisible box on the page. These boxes stack and nest according to the document structure. In Chapter 2, we'll learn to control these boxes with CSS. For now, understand that structure creates boxes, and boxes create layout. ## Business Applications ### Search Engine Optimisation (SEO) Search engines read your HTML structure to understand your content. A well-structured page with clear headings, semantic sections, and meaningful hierarchy ranks better than a soup of `` elements. ### Accessibility Screen readers—software used by visually impaired people—navigate by structure. Users can jump between headings, skip to main content, or list all navigation links. Without semantic HTML, this navigation is impossible. This isn't just ethical—it's often legal. Many jurisdictions require accessible websites for businesses, government, and education. ### Maintainability Well-structured HTML is easier to update. When sections are clearly marked, finding and changing content takes minutes instead of hours. Six months from now, you (or someone else) will thank you for clean structure. ### Professional Credibility When potential employers or clients view your page source, structure tells them about your professionalism. Clean, semantic HTML signals someone who understands web fundamentals—not just someone who copied code until something worked. ## ULO Connection This develops ULO 1 (design and evaluate effective web applications) and ULO 2 (professional skills). Structure isn't visible to casual viewers, but it's visible to search engines, screen readers, developers, and anyone who inspects your code. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 1.1: Document Analysis (Level 1) Find a simple webpage (a local business, a restaurant, a small company). View its source (right-click → View Page Source). Identify: 1. The `` declaration 2. The `` and `` sections 3. At least three semantic elements (``, ``, ``, ``, ``, ``) 4. The heading hierarchy (`` through ``) Document your findings. Is this page well-structured or poorly structured? Why? ### Exercise 1.2: Structure First (Level 2) Without writing any HTML, create a structural outline for a personal portfolio page. List: - What would go in the header? - What sections would the main content have? - What information belongs in the footer? - What's the heading hierarchy? Then, with your AI partner, translate your outline into semantic HTML. Compare your outline with the final code—did the structure remain clear? ### Exercise 1.3: Fix the Structure (Level 3) Here's a poorly structured page. Identify the problems and rewrite it with proper semantic HTML: List each problem you find and explain why it matters. ### Exercise 1.4: Business Requirements (Level 4) A local bakery asks you to create their website. They mention: - They want their hours prominently displayed - They have three categories of products (bread, pastries, cakes) - They want to show their story and values - They need contact information and a map Create a structural plan that addresses their requirements. Which semantic elements would you use for each requirement? Justify your choices in business terms—why does proper structure benefit this bakery? ### Exercise 1.5: Semantic Debate (Level 5) Should a "team members" section on an About page use `` for each person, or ``, or neither? Research the HTML specification's definitions for both elements. Have a conversation with your AI partner exploring arguments for each choice. Write a short recommendation (200-300 words) defending your position with evidence from web standards. This exercise has no single correct answer—it develops your ability to make and defend technical decisions (ULO 4). ## Chapter Summary - HTML describes document structure, not appearance - Semantic elements convey meaning to humans and machines - Every page has `` (metadata) and `` (content) - Headings create hierarchy—don't skip levels or use them for styling - Structure benefits SEO, accessibility, maintainability, and professionalism - The structure you create is as important as the content you write ## Reflection Before moving to Chapter 2, ensure you can: - [ ] Explain HTML's purpose without using technical jargon - [ ] Identify at least six semantic HTML elements and their purposes - [ ] Describe the difference between semantic and presentational markup - [ ] Create a document outline before writing code - [ ] Explain why structure matters for business (SEO, accessibility, maintenance) - [ ] View a page's source and assess its structural quality - [ ] Have a productive conversation with AI about HTML concepts ## Your Learning Journal Record your responses to these prompts: 1. Structure Spotting: Look at three websites you use regularly. What structural patterns do they share? What semantic elements can you identify? 2. AI Conversation Reflection: What was the most useful question you asked your AI partner in this chapter? What made it effective? 3. Concept Connection: How does HTML structure relate to other kinds of structure you encounter (documents, buildings, organisations)? 4. Lingering Questions: What aspects of HTML structure are still unclear? Write these as questions to explore with your AI partner. ## Next Steps You now understand how to describe what content is. But a page with only HTML looks plain—black text on white background, default fonts, minimal layout. In , we'll explore CSS—how to control the visual presentation of our structured content. Structure and presentation are deliberately separate in web development, and understanding why is key to professional practice. The structure you've learned to create becomes the foundation that CSS styles. Good structure makes styling straightforward; poor structure makes it a struggle. ============================================================ SOURCE: chapters/chapter-presentation.qmd ============================================================ # Presentation: CSS as Visual Communication ## The Concept First In , you learned to describe what content is. Now we'll control how content looks—but this isn't decoration. It's visual communication. CSS (Cascading Style Sheets) determines colours, fonts, spacing, and layout. But these choices aren't arbitrary. Every visual decision communicates something: professionalism, playfulness, urgency, calm. A hospital website and a children's toy store might have identical HTML structure, but their CSS tells completely different stories. Here's the key insight: structure and presentation are deliberately separate. Your HTML says "this is a heading"—it doesn't say "this should be blue and 24 pixels tall." CSS handles appearance. This separation means you can completely redesign a website without touching its content, or update content without breaking the design. ## Understanding Through Design Think of two cafés with identical menus. Same coffee, same pastries, same prices. Café A: Exposed brick, warm lighting, comfortable armchairs, handwritten chalkboard menu, soft jazz playing. Café B: White walls, fluorescent lights, plastic chairs, printed menu in a laminated folder, no music. The content is identical—but would you feel the same about visiting each one? The atmosphere shapes your entire perception of the business. One feels welcoming and worth paying premium prices; the other feels like a waiting room. CSS is your website's atmosphere. The content (HTML) might be excellent, but if the presentation feels amateur, untrustworthy, or confusing, users leave. ## The Atmosphere Test Look at any website and ask: "What is this design trying to communicate?" Before you read the words, the visual design has already told you whether this is playful or serious, cheap or premium, trustworthy or suspicious. ## Discovering Presentation with Your AI Partner ### Exploration 1: Why Separate Structure and Style? This conversation should reveal the power of separation: one set of content, many possible presentations. News services send identical stories to papers worldwide, but each paper styles them differently. Similarly, your HTML content can have different CSS applied for screen, print, mobile, or accessibility needs. Follow up: ### Exploration 2: Mobile-First as Business Strategy More than half of web traffic comes from mobile devices. But mobile-first isn't just about phones—it's a design philosophy. Your AI should explain how mobile constraints force clarity: limited space means prioritising what matters, slow connections mean optimising performance, touch targets mean accessible interfaces. Designing for these constraints first creates better experiences everywhere. ### Exploration 3: Visual Hierarchy Every page has multiple elements competing for attention. Visual hierarchy tells users what to look at first, second, third—guiding them through your content intentionally. This should reveal tools beyond size: colour contrast, whitespace, position, typography weight. A small red button can dominate over a large grey headline because colour attracts attention. ## From Concept to Code Let's build your CSS understanding progressively, from basic syntax to practical layouts. ### CSS Syntax: Selectors, Properties, Values CSS follows a simple pattern: The selector identifies which HTML elements to style. The property is what aspect to change. The value is what to change it to. This says: "Find all `` elements. Make their text navy. Make them 2rem (roughly 32 pixels) tall." ### Connecting CSS to HTML CSS can live in three places: External stylesheet (recommended for most work): Internal stylesheet (in the HTML file): Inline styles (on individual elements—generally avoid): External stylesheets keep presentation separate from structure. One CSS file can style an entire website, and changes propagate everywhere instantly. ### Common Selectors Selectors target elements in different ways: Classes (`.classname`) are your workhorses—reusable styles you can apply to any element. IDs (`#idname`) should be unique per page and are less commonly used in modern CSS. ### The Box Model Every HTML element generates a rectangular box. Understanding this box model is essential for layout: - Content: The actual text or image - Padding: Space between content and border (inside the box) - Border: The edge of the box - Margin: Space outside the border (between boxes) ## Box-Sizing Gotcha By default, width and height don't include padding or border. A 200px box with 20px padding becomes 240px wide. Modern practice is to add `box-sizing: border-box;` so width includes everything: This makes layout calculations much more intuitive. ### Layout with Flexbox Flexbox is the modern way to arrange elements. It makes previously difficult tasks—like centring or equal-height columns—simple. This single line transforms the container. Its children become "flex items" that can be arranged in powerful ways: Common flex patterns: Navigation bar: Centred content: Card grid (with wrap): ### Responsive Design: Media Queries Responsive design adapts layout to different screen sizes. Media queries let you apply CSS conditionally: Mobile-first means your base CSS is for mobile, then you add complexity for larger screens. This approach naturally prioritises essential content. ### Typography and Colour Basics Typography and colour have immediate visual impact: Using `rem` for sizes keeps everything relative to the base font size, making your design more adaptable: ## Building Your Mental Model ### The Cascade: Why "Cascading"? CSS rules can conflict. When multiple rules target the same element, the cascade determines which wins: 1. Specificity: More specific selectors win (`#id` beats `.class` beats `element`) 2. Source order: Later rules override earlier ones (if specificity is equal) 3. Importance: `!important` overrides everything (but avoid using it) ### The Flow: Block vs Inline HTML elements have default display behaviours: Block elements (``, ``, ``, ``): - Stack vertically - Take full available width - Can have width and height set Inline elements (``, ``, ``): - Flow horizontally with text - Take only the space they need - Cannot have width and height set (use `display: inline-block` if needed) Understanding flow explains why elements appear where they do before you apply any layout CSS. ### The Mental Stack When you look at a webpage, think in layers: 1. Content layer (HTML): What exists 2. Style layer (CSS): How it looks 3. Behaviour layer (JavaScript, Chapter 3): How it responds CSS only controls layer 2. It can't create content or make things interactive—it controls visual presentation of whatever HTML provides. ## Business Applications ### Brand Consistency CSS variables (custom properties) enforce brand standards across an entire site: Change the variable once, and every element using it updates instantly. This is how large organisations maintain consistency across dozens of pages. ### User Experience and Trust Studies consistently show that users judge website credibility in milliseconds, based primarily on visual design. Professional presentation builds trust; amateur presentation creates suspicion—regardless of how good the actual content is. ### Mobile Reach If your site doesn't work on mobile, you're excluding over half your potential audience. Responsive design isn't a feature—it's a baseline requirement for any business website. ### Conversion and Visual Hierarchy Where users look determines what they do. Visual hierarchy guides attention to calls-to-action, important information, and conversion points. Poor hierarchy means users miss what matters. ## ULO Connection This develops ULO 1 (effective web applications) and ULO 4 (technology selection). CSS choices affect user experience, brand perception, and business outcomes. The ability to evaluate and implement appropriate visual design is essential professional skill. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 2.1: Style Inspection (Level 1) Using browser DevTools (right-click → Inspect), examine a website you use regularly: 1. Find an element and identify its box model (content, padding, border, margin) 2. Locate where its colour is defined in the CSS 3. Find a media query and identify what changes at different screen sizes 4. Identify at least one flexbox container Document your findings with screenshots. ### Exercise 2.2: Basic Styling (Level 2) Take the semantic HTML page from Chapter 1's exercises. Create an external stylesheet that: 1. Sets a readable base font and line height 2. Styles the header with a background colour 3. Adds appropriate padding to sections 4. Creates visual distinction between the main content and footer Focus on readability and visual hierarchy—not decoration. ### Exercise 2.3: Responsive Layout (Level 3) Create a "features" section with three items. Each item has: - An icon or emoji placeholder - A heading - A short description Using flexbox, make this: - Single column on mobile (under 768px) - Three columns on desktop Write the CSS mobile-first, adding complexity with media queries. ### Exercise 2.4: Design Analysis (Level 4) Find two competing businesses in the same industry (e.g., two accounting firms, two coffee shops). Analyse their websites: 1. How does each use visual hierarchy? What's emphasised? 2. What do their colour choices communicate? 3. How does typography differ and what does it suggest? 4. Which feels more trustworthy? Why? Write a 300-word comparison explaining how CSS choices reflect (or undermine) each brand's positioning. ### Exercise 2.5: Design System (Level 5) Create a mini design system for a hypothetical business. Define: 1. A colour palette (primary, secondary, accent, text, background) 2. Typography choices (headings, body, sizes) 3. Spacing scale (consistent padding/margin values) 4. A set of CSS variables implementing these choices Document your decisions: why these colours? Why these fonts? How do these choices communicate the brand personality? Apply your system to style a simple page, then have your AI partner critique it. ## Chapter Summary - CSS controls visual presentation separately from HTML structure - The box model (content, padding, border, margin) explains how elements take space - Flexbox provides powerful, intuitive layout capabilities - Media queries enable responsive design that adapts to any device - Visual design communicates brand, builds trust, and guides user attention - Mobile-first design creates better experiences for everyone ## Reflection Before moving to Chapter 3, ensure you can: - [ ] Explain why structure and presentation are separate - [ ] Write CSS selectors to target specific elements - [ ] Describe the box model and how padding differs from margin - [ ] Create flexible layouts with flexbox - [ ] Write mobile-first CSS using media queries - [ ] Articulate how visual design affects business outcomes - [ ] Use browser DevTools to inspect and understand CSS ## Your Learning Journal Record your responses to these prompts: 1. Design Awareness: Look at three websites with very different visual styles. How does each CSS approach reflect its purpose and audience? 2. Mobile Testing: View a website you built (or one you use) on your phone. What works well? What's frustrating? How would you improve it? 3. AI Conversation Reflection: What CSS concept was hardest to grasp? What question to your AI partner helped clarify it? 4. Business Connection: Think of a business you might create a website for. What visual atmosphere would best serve that business? Why? ## Next Steps You now control both structure (HTML) and presentation (CSS). But websites today aren't just documents to read—they're applications to interact with. In , we'll add JavaScript—the third pillar of web development. JavaScript lets pages respond to user actions: clicks, scrolls, form submissions. It transforms static documents into dynamic experiences. The HTML structure and CSS styling you've learned become the canvas that JavaScript brings to life. ============================================================ SOURCE: chapters/chapter-behaviour.qmd ============================================================ # Behaviour: JavaScript as User Interaction ## The Concept First HTML provides structure. CSS provides presentation. JavaScript provides behaviour—the ability to respond to user actions, update content dynamically, and create interactive experiences. Consider a contact form. HTML creates the fields and the submit button. CSS makes it look professional. But what happens when someone clicks "Submit"? What validates their input? What shows them a success message? That's JavaScript. JavaScript transforms static documents into dynamic applications. It's what makes modern web experiences feel responsive and alive—dropdown menus that expand, forms that validate as you type, content that loads without page refreshes. But here's an important perspective: JavaScript should enhance, not replace, structure and presentation. A well-built page works without JavaScript. JavaScript makes it work better. ## Understanding Through Conversation A static webpage is like a poster on a wall. You can look at it, but it can't respond to you. It just... sits there. JavaScript makes your page more like a conversation: - It listens: "The user clicked this button" - It thinks: "I should validate the form now" - It responds: "Show the error message next to the email field" - It adapts: "Now that they've fixed the email, remove the error" This back-and-forth is called event-driven programming. Instead of running top to bottom like a recipe, JavaScript waits for things to happen (events) and responds to them. ## The Conversation Mindset When designing interactive features, think: "What might the user do?" (events) and "How should the page respond?" (handlers). Every interaction is a small conversation between user and page. ## Discovering Behaviour with Your AI Partner ### Exploration 1: Event-Driven Thinking The event-driven model is fundamental to understanding JavaScript. Let's explore it through analogy: This should reveal the pattern: staff don't constantly poll customers. Instead, customers signal (raise a hand, make eye contact) and staff respond. Events trigger responses. Follow up: ### Exploration 2: The DOM JavaScript interacts with pages through something called the DOM (Document Object Model). But what is it? The DOM is JavaScript's representation of your HTML structure. When you change the DOM, the page updates visually. It's the bridge between your code and what users see. ### Exploration 3: Progressive Enhancement Here's a philosophy that separates professional developers from amateurs: This conversation should reveal important realities: some users disable JavaScript for security, some have slow connections where it fails to load, some use assistive technologies that struggle with JS-heavy sites, and some corporate firewalls block scripts. Building core functionality in HTML and CSS, then enhancing with JavaScript, serves more customers. ## From Concept to Code Let's build your JavaScript understanding progressively, from basic syntax to handling user interactions. ### Where JavaScript Lives Like CSS, JavaScript can be placed in different locations: External file (recommended): Inline in HTML (for small scripts): Place `` tags at the end of `` so HTML loads first. This ensures elements exist before JavaScript tries to interact with them. ### Variables: Storing Information Variables hold data that can change: Use `const` by default—it prevents accidental changes. Use `let` only when you need to reassign the value. ## Avoid `var` You'll see `var` in older code and some AI-generated examples. It has confusing scoping rules. Modern JavaScript uses `let` and `const` exclusively. If your AI suggests `var`, ask it to use `let` or `const` instead. ### Data Types JavaScript handles several types of data: ### Functions: Reusable Actions Functions group code that performs a specific task: Functions take inputs (parameters), do something, and optionally return a result. They're how you organise code into manageable, reusable pieces. Arrow function syntax (modern, compact): Both syntaxes work. Arrow functions are common in modern code, especially for short operations. ### Finding Elements: Querying the DOM To interact with page elements, first you must find them: `querySelector` uses CSS selector syntax—the same patterns you learned in Chapter 2. This consistency makes finding elements intuitive. ### Changing Elements Once you've found an element, you can modify it: ## Classes Over Inline Styles Instead of setting `element.style.color = 'red'`, add a class that has those styles. This keeps your CSS in CSS and your JavaScript focused on behaviour. ### Events: Responding to Users Events are things that happen—clicks, key presses, form submissions, page loads. Event listeners wait for specific events and run code when they occur: The pattern is: `element.addEventListener(eventType, handlerFunction)` Common events: | Event | Triggered When | |-------|---------------| | `click` | User clicks the element | | `submit` | Form is submitted | | `input` | Input value changes | | `keydown` | Key is pressed | | `mouseover` | Mouse enters element | | `load` | Page finishes loading | ### A Complete Example: Toggle Menu Let's combine these concepts into a practical feature—a mobile navigation toggle: This is progressive enhancement: the HTML structure exists, the CSS hides the menu by default on mobile, and JavaScript adds the toggle behaviour. If JavaScript fails, you could add `class="hidden"` via CSS media queries so the menu shows on larger screens regardless. ### Form Validation Example Here's a practical business example—validating an email field: This validates as the user types and again on submission. Note: HTML5 provides `type="email"` validation too—JavaScript enhances the feedback, not replaces the baseline. ## Building Your Mental Model ### The Event Loop JavaScript doesn't run all at once. It: 1. Loads and runs initial code 2. Waits for events 3. When an event occurs, runs the handler 4. Returns to waiting This is why you register event listeners—you're telling JavaScript "when this happens, run this code." The rest of the time, JavaScript is idle, waiting. ### The Three Layers Reinforce this mental model from earlier chapters: Each layer builds on the one below. JavaScript manipulates the DOM (HTML structure), which CSS then styles. Keeping these layers separate makes code maintainable. ### Debugging with Console The browser console is your debugging friend: Open DevTools (F12 or right-click → Inspect → Console) to see these messages. When something doesn't work, add `console.log()` statements to trace what's happening. ## Business Applications ### User Engagement Interactive features keep users engaged. Think: image galleries, accordion FAQs, live search filtering. Each interaction is an opportunity to help users find what they need. ### Form Validation and Data Quality Client-side validation prevents bad data before it reaches your server. This improves data quality, reduces support requests, and creates a smoother user experience. ## Security Note Client-side validation improves user experience, but never trust it for security. Users can disable JavaScript or modify your code. Always validate on the server too. ### Dynamic Content Loading content without page refreshes (covered more in Chapter 4) makes applications feel faster. Users don't wait for full page reloads when they just need one small update. ### Analytics and User Behaviour JavaScript can track how users interact with your site: what they click, how far they scroll, where they spend time. This data informs business decisions. (Always be transparent about tracking and respect privacy.) ## ULO Connection This develops ULO 1 (effective web applications) and ULO 3 (translating stakeholder needs). Interactive features must serve user needs—JavaScript for its own sake creates complexity without value. The ability to identify when interactivity helps versus hinders is professional judgment. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 3.1: Console Exploration (Level 1) Open any webpage and open the browser console (F12 → Console). Try these: 1. Type `document.title` and press Enter. What appears? 2. Type `document.querySelector('h1')` to find the main heading 3. Type `document.querySelector('h1').textContent = 'I changed this!'` What happened? Refresh the page—is your change permanent? Why or why not? ### Exercise 3.2: Button Interaction (Level 2) Create an HTML page with a button and a paragraph. Write JavaScript that: 1. Listens for clicks on the button 2. Changes the paragraph text when clicked 3. Also changes the paragraph's colour (via adding a class) Test it in your browser. Use `console.log()` to confirm your click handler runs. ### Exercise 3.3: Character Counter (Level 3) Create a textarea with a character limit display, like social media post composers: 1. Show "0 / 280 characters" below the textarea 2. Update the count as the user types (use the `input` event) 3. Change the counter colour to red when approaching or exceeding the limit 4. Disable the submit button if over the limit This combines DOM queries, event listeners, conditionals, and class manipulation. ### Exercise 3.4: Progressive Enhancement Audit (Level 4) Find a website that heavily uses JavaScript (a web application). Disable JavaScript in your browser (Settings → Privacy → JavaScript) and try to use the site. 1. What still works? 2. What breaks completely? 3. For the broken features, how could they have been built with progressive enhancement? Write a 300-word assessment of this site's JavaScript dependency and its business implications. ### Exercise 3.5: Interactive Feature Design (Level 5) A local bookshop wants their website to have an interactive "Book Finder" feature. Users should be able to filter books by genre, search by title, and sort by price or rating. 1. Design the HTML structure needed 2. Identify what events you'd listen for 3. Describe what JavaScript would do for each interaction 4. Consider: what should work without JavaScript? Don't write the full code—design the approach. Document your thinking, then discuss your design with your AI partner. What did they suggest differently? ## Chapter Summary - JavaScript adds behaviour—the ability to respond to user actions - Event-driven programming means listening for events and responding - The DOM is JavaScript's interface to the page structure - Progressive enhancement builds on working HTML/CSS, not replacing it - Debugging with `console.log()` helps trace problems - Interactive features should serve user needs, not demonstrate technical skill ## Reflection Before moving to Chapter 4, ensure you can: - [ ] Explain event-driven programming in plain language - [ ] Write basic JavaScript: variables, functions, conditionals - [ ] Find elements in the DOM using `querySelector` - [ ] Attach event listeners to respond to user actions - [ ] Modify element content, classes, and styles via JavaScript - [ ] Articulate why progressive enhancement matters for business - [ ] Use the browser console for basic debugging ## Your Learning Journal Record your responses to these prompts: 1. Interaction Audit: Look at a website you use frequently. What interactive features does it have? For each one, describe what event triggers it and what the response is. 2. Progressive Enhancement Thinking: Think of a common web feature (like a dropdown menu or image carousel). How would you build it so it works without JavaScript? 3. AI Conversation Reflection: What JavaScript concept was hardest to grasp? What question to your AI partner helped clarify it? 4. Business Value: When does adding JavaScript interactivity help users, and when does it just add complexity? Give examples of each. ## Next Steps You can now build pages that respond to users. But modern web applications do more—they connect to services, fetch data, and send information to servers. In , we'll explore APIs—how your JavaScript can request data from external services and submit data to be processed. This transforms your pages from standalone documents into connected applications that interact with the wider web. The JavaScript fundamentals you've learned become the foundation for asynchronous programming and data-driven interfaces. ============================================================ SOURCE: chapters/chapter-connection.qmd ============================================================ # Connection: APIs as Business Integration ## The Concept First So far, everything you've built lives in isolation. Your HTML, CSS, and JavaScript create an experience, but that experience is self-contained—it doesn't connect to anything beyond itself. Real business applications are different. They display live weather data. They process payments. They show inventory levels. They sync with customer databases. They pull content from external services. How? APIs—Application Programming Interfaces. An API is a defined way for two systems to communicate. When your JavaScript asks a weather service "What's the temperature in Perth?", it's using an API. When a customer's payment details go to Stripe for processing, that's an API. When your portfolio site pulls your latest GitHub projects, that's an API. APIs transform your website from a standalone document into a connected application that interacts with the wider world. ## Understanding Through Contracts Think of an API as a contract between two parties. Like any good contract, it specifies: - What you can ask for (the endpoints) - How to ask (the request format) - What you'll receive (the response format) - What happens if something goes wrong (error handling) Imagine a restaurant: - The menu lists what you can order (available endpoints) - You place an order in a specific way—verbally to a waiter, on a printed slip (request format) - The kitchen prepares your food and the waiter delivers it (response) - If something's unavailable, they tell you (error response) You don't need to know how the kitchen works. You just need to know how to order and what to expect. That's the power of a well-defined interface. ## The Contract Mindset When working with any API, first understand the contract: What can I request? What format does it expect? What will I receive? What errors might occur? Read the documentation before writing code. ## Discovering Connection with Your AI Partner ### Exploration 1: How APIs Work Let's build understanding before we see code: This should reveal the core pattern: APIs expose resources (data) and let you perform operations on them. The operations typically map to HTTP methods: GET (read), POST (create), PUT/PATCH (update), DELETE (remove). ### Exploration 2: Data Formats APIs need a common language for data. That language is usually JSON. JSON (JavaScript Object Notation) is readable by humans and easily parsed by machines. It's become the universal format for web data exchange. ### Exploration 3: What Can Go Wrong? Network requests fail. Servers go down. Data doesn't match expectations. Professional applications handle these gracefully. Understanding failure modes is essential. Your code must handle them or your users will see cryptic errors—or worse, a completely broken page. ## From Concept to Code Let's build your API understanding progressively, from fetching data to handling complex scenarios. ### The Fetch API JavaScript's `fetch()` function makes HTTP requests: This fetches data from a URL, converts the response to JSON, and logs it. But what's with all those `.then()` calls? ### Understanding Asynchronous Code API requests take time. The server might be across the world. Your code can't just wait—it would freeze the entire page. JavaScript handles this with asynchronous code. Instead of stopping and waiting, it says "start this request, and when it's done, run this code." The `.then()` pattern is called a Promise. But modern JavaScript has a cleaner syntax: `async`/`await`. ### Async/Await: Readable Asynchronous Code `await` pauses the function (not the whole page) until the operation completes. The `async` keyword marks functions that use `await`. This reads more naturally: "Fetch the URL. Wait. Parse the JSON. Wait. Log the data." ### A Complete Example: Displaying API Data Let's fetch real data and display it: ```javascript async function displayProducts() { const container = document.querySelector('#product-list'); try { const response = await fetch('https://fakestoreapi.com/products?limit=3'); const products = await response.json(); // Clear loading message container.innerHTML = ''; // Create HTML for each product products.forEach(product => { const productCard = document.createElement('div'); productCard.classList.add('product-card'); productCard.innerHTML = ` ${product.title} $${product.price} `; container.appendChild(productCard); }); } catch (error) { container.innerHTML = 'Sorry, products could not be loaded.'; console.error('Fetch failed:', error); } } displayProducts(); ``` Key elements: 1. Show a loading state initially 2. Fetch data with `await` 3. Parse JSON with `await` 4. Create DOM elements for each item 5. Handle errors with `try`/`catch` ### Working with JSON Data JSON data looks like JavaScript objects: Accessing data uses dot notation or brackets: For arrays of items: ### Error Handling in Depth Robust applications handle multiple failure scenarios: ```javascript async function loadData() { try { const response = await fetch('https://api.example.com/data'); // Check if the response was successful if (!response.ok) { throw new Error(`HTTP error: ${response.status}`); } const data = await response.json(); return data; } catch (error) { if (error.name === 'TypeError') { // Network failure - couldn't reach the server console.error('Network error:', error); return { error: 'Unable to connect. Please check your internet.' }; } else { // Other error (including our HTTP error) console.error('Fetch error:', error); return { error: 'Something went wrong. Please try again.' }; } } } ``` ## Check `response.ok` A `fetch()` that reaches the server won't throw an error even if the server returns a 404 or 500 status. You must check `response.ok` to detect these failures. ### Loading States Users should never see a blank screen while waiting: The `finally` block runs regardless of success or failure—perfect for cleanup like hiding loading spinners. ### HTTP Methods: Beyond GET So far we've used GET (fetching data). Other methods exist: | Method | Purpose | Has Body? | |--------|---------|-----------| | GET | Read data | No | | POST | Create new data | Yes | | PUT | Replace data completely | Yes | | PATCH | Update part of data | Yes | | DELETE | Remove data | Usually no | ### CORS: Why Some Requests Fail You might encounter this error: > Access to fetch at 'https://other-site.com/api' has been blocked by CORS policy CORS (Cross-Origin Resource Sharing) is a security feature. By default, JavaScript can only fetch from the same domain the page is on. To fetch from a different domain, that domain must explicitly allow it. As a frontend developer, you can't fix CORS on a third-party server. Your options: 1. Use APIs that allow CORS (most public APIs do) 2. Ask the API provider to enable CORS 3. Use a backend proxy (your server fetches the data) ## Public APIs for Practice Many APIs welcome frontend requests: JSONPlaceholder, OpenWeatherMap, GitHub API, and more. These are great for learning. ## Building Your Mental Model ### Request-Response Cycle Every API interaction follows this pattern: 1. Your JavaScript builds a request (URL, method, body, headers) 2. Browser sends it across the network 3. Server processes and responds 4. Your JavaScript handles the response Everything that can go wrong—network issues, server errors, malformed data—happens in this cycle. ### Synchronous vs Asynchronous `async`/`await` makes asynchronous code look synchronous while keeping the page responsive. ### The Data Flow Understanding this flow helps debug issues: Is the problem in fetching? Parsing? Processing? Rendering? ## Business Applications ### Real-Time Data Stock prices, sports scores, weather—APIs provide live data that keeps users engaged and informed. Without APIs, you'd need to manually update your site constantly. ### Payment Processing No one stores credit cards themselves (the liability is enormous). Payment APIs like Stripe, PayPal, and Square handle the sensitive parts, letting you focus on the shopping experience. ### Third-Party Services Maps (Google Maps, Mapbox), analytics (Google Analytics), authentication (Auth0), email (SendGrid)—APIs let you leverage sophisticated services without building them yourself. ### Scalability and Architecture Separating your frontend (the user interface) from your backend (the data and business logic) via APIs allows each to scale independently. Your static site can be served from a CDN worldwide while your API runs on dedicated servers. ### Business Integration Connect your website to: - Inventory management systems - Customer relationship management (CRM) - Email marketing platforms - Accounting software APIs are how modern businesses connect their systems. ## ULO Connection This develops ULO 4 (select and integrate technologies) and ULO 1 (design effective applications). API integration is fundamental to modern web development. Understanding how to evaluate, implement, and handle errors in API connections is essential professional knowledge. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 4.1: Your First API Call (Level 1) Use the JSONPlaceholder API (`https://jsonplaceholder.typicode.com/posts/1`) to: 1. Fetch a single post using `fetch()` and `async`/`await` 2. Log the response to the console 3. Display the post's title and body in HTML elements Open DevTools Network tab to see the request and response. ### Exercise 4.2: Displaying a List (Level 2) Fetch multiple posts from `https://jsonplaceholder.typicode.com/posts?_limit=5` and: 1. Create an HTML card for each post showing title and body 2. Add proper loading and error states 3. Style the cards with CSS Handle what happens if the fetch fails. ### Exercise 4.3: Dynamic Filtering (Level 3) Using the JSONPlaceholder posts API: 1. Fetch all posts (or limit to 20) 2. Create a search input field 3. As the user types, filter the displayed posts to those whose title contains the search term 4. Update the display without re-fetching This combines API fetching with JavaScript event handling and DOM manipulation. ### Exercise 4.4: Error Handling Scenarios (Level 4) Create a page that fetches from an API and handles all these scenarios gracefully: 1. Successful fetch → Display data 2. Network error (try an invalid URL) → Show connection error message 3. 404 error (fetch a non-existent resource) → Show "not found" message 4. Loading state → Show spinner while waiting Test each scenario and document how you handled them. Take screenshots showing each state. ### Exercise 4.5: API Integration Proposal (Level 5) A local gym wants to display class schedules from their booking system on their website. The booking system has an API. Research and propose: 1. What data would you need from the API? 2. How would you display it? (Sketch the UI) 3. What loading states and error handling are needed? 4. How often should data refresh? 5. What happens if the API is unavailable? Write a 400-word proposal. Discuss your approach with your AI partner—what did you miss? ## Chapter Summary - APIs enable systems to communicate through defined contracts - `fetch()` with `async`/`await` makes readable asynchronous code - JSON is the standard data format for web APIs - Always handle loading states and errors - Check `response.ok`—fetch doesn't throw on HTTP errors - CORS protects users but can block legitimate requests - APIs connect your site to the broader ecosystem of services ## Reflection Before moving to the Portfolio Project, ensure you can: - [ ] Explain what an API is without technical jargon - [ ] Write a `fetch()` request using `async`/`await` - [ ] Parse JSON responses and access nested data - [ ] Handle loading states appropriately - [ ] Implement error handling with `try`/`catch` - [ ] Explain the difference between GET and POST - [ ] Articulate why APIs matter for business applications ## Your Learning Journal Record your responses to these prompts: 1. API Discovery: Find three public APIs that could be useful for business websites. What data do they provide? What would you build with them? 2. Error Empathy: Think about times you've seen error messages on websites. Which were helpful? Which were frustrating? How would you do better? 3. AI Conversation Reflection: What API concept was most confusing? What question to your AI partner helped clarify it? 4. Business Integration: Think of a local business. What data might they want to display from external sources? What APIs might provide it? ## Next Steps You've now completed Part I: Web Foundations. You understand: - Structure (HTML): What content exists - Presentation (CSS): How content looks - Behaviour (JavaScript): How content responds - Connection (APIs): How content integrates with external services In , you'll combine these skills to build a complete portfolio website—your first substantial web project. This portfolio will demonstrate your capabilities to future employers or clients. Then, in Part II, we shift focus from building pages to managing content at scale with content management systems. ============================================================ SOURCE: projects/project-portfolio.qmd ============================================================ # Project: Portfolio Website ## Project Overview Your first substantial project brings together everything from Part I: Structure (HTML), Presentation (CSS), Behaviour (JavaScript), and Connection (APIs). You'll build a personal portfolio website—a professional asset that demonstrates your capabilities to future employers or clients. This isn't just an academic exercise. A well-crafted portfolio is one of the most valuable tools for launching a career in web development or digital business. ## Learning Outcomes Addressed - ULO 1: Design, implement, and evaluate effective business web applications - ULO 3: Analyse stakeholder requirements to inform design decisions - ULO 5: Evaluate and apply appropriate web technologies ## The Business Case Consider this project from a business perspective. Your portfolio serves multiple stakeholders: - Potential employers want to see what you can build and how you think - Clients want confidence that you understand professional standards - You need a platform to showcase growth over time Ask yourself: What does your portfolio need to communicate? Not just "I can code" but "I understand business needs, I write clean code, I think about users." ## Requirements ### Functional Requirements Your portfolio must include: 1. Home page: Clear introduction establishing who you are and what you do 2. About section: Your background, skills, and professional interests 3. Projects showcase: At least three projects or work samples with descriptions 4. Contact information: How someone can reach you professionally 5. Responsive design: Works well on mobile, tablet, and desktop 6. API integration: At least one meaningful use of external data ### Technical Requirements | Requirement | Standard | |------------|----------| | HTML | Semantic HTML5 (appropriate use of ``, ``, ``, ``, ``, etc.) | | CSS | Mobile-first responsive design with Flexbox/Grid | | JavaScript | At least one interactive feature using event listeners | | API | At least one API call displaying external data | | Accessibility | Basic WCAG 2.1 AA compliance (semantic structure, alt text, colour contrast, keyboard navigation) | | Version control | Git repository with meaningful commit history | | Deployment | Live URL (GitHub Pages, Netlify, or similar) | ### What Counts as API Integration? Choose one or more: - GitHub API: Display your repositories or contribution activity - Weather API: Show local weather (perhaps themed to where you're based) - Quote API: Display rotating inspirational or industry quotes - JSON data file: If external APIs are problematic, create your own JSON file of project data and fetch it - Other: Any public API that adds genuine value (not just demonstrating you can fetch data) The integration should be meaningful—it should serve a purpose for someone viewing your portfolio, not just prove you can make an API call. ## Project Approach ### Phase 1: Planning (Before Any Code) 1. Define your audience: Who will view this portfolio? What do they need? 2. Content inventory: List all the content you'll need (text, images, project descriptions) 3. Structure outline: Sketch your page structure—what sections, what hierarchy? 4. Visual direction: What atmosphere suits your professional identity? ### Phase 2: HTML Structure Build your complete HTML structure before styling: 1. Create semantic markup for all pages/sections 2. Validate your HTML (W3C Validator) 3. Test that the content makes sense without any CSS 4. Ensure heading hierarchy is logical (h1 → h2 → h3, no skipping) This phase should produce an "ugly but functional" page—all content present, properly structured, but unstyled. ### Phase 3: CSS Styling Apply styles mobile-first: 1. Base styles (typography, colours, spacing) 2. Mobile layout (single column, readable) 3. Tablet breakpoint (adjust layout as needed) 4. Desktop breakpoint (multi-column where appropriate) 5. Interactive states (hover, focus) ### Phase 4: JavaScript Interactivity Add behaviour that enhances the experience: 1. Navigation toggle for mobile 2. Smooth scrolling to sections (optional) 3. Form validation (if you have a contact form) 4. Any other interactive features Remember progressive enhancement: your site should work without JavaScript. ### Phase 5: API Integration Implement your API feature: 1. Choose an appropriate API 2. Handle loading states 3. Handle errors gracefully 4. Display data meaningfully ### Phase 6: Testing and Refinement 1. Test on multiple devices (or device emulators) 2. Test with keyboard navigation only 3. Run accessibility audit (Lighthouse, WAVE) 4. Fix any issues found 5. Get feedback from peers ## AI Collaboration Guidelines ### How to Use AI Effectively This project is an opportunity to practice the collaboration skills from . Use AI to: - Explore approaches before committing - Debug issues you can't resolve - Get feedback on code quality - Understand why something works, not just that it works Do not use AI to: - Generate your entire project and submit it - Write content about yourself (you know yourself better) - Skip understanding what the code does ### Documentation Requirements Keep an AI collaboration log documenting: 1. Prompts that helped: What questions got useful responses? 2. Modifications you made: How did you adapt AI suggestions? 3. AI errors or limitations: What did AI get wrong? How did you know? 4. Learning moments: What did the collaboration teach you? This log demonstrates critical thinking—that you're directing the AI, not just copying its output. ### Example Log Entry ## Evaluation Criteria ### Structure and Semantics (20%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | HTML semantics | Excellent use of semantic elements; clear document outline | Good semantic structure with minor issues | Basic semantic elements present | Mostly `` elements; poor semantics | | Heading hierarchy | Logical hierarchy throughout; single h1 | Mostly logical; minor inconsistencies | Headings present but some skipped levels | Headings used for styling, not structure | | Document validity | Valid HTML5; no errors | Minor validation warnings | Some validation errors | Multiple validation errors | ### Presentation and Responsiveness (25%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Mobile-first CSS | Clear mobile-first approach; logical breakpoints | Mostly mobile-first with some exceptions | Responsive but desktop-first | Not responsive or broken on devices | | Visual design | Professional appearance; clear hierarchy; consistent styling | Attractive design; minor inconsistencies | Functional design; some visual issues | Unprofessional or inconsistent styling | | Layout | Effective use of Flexbox/Grid; balanced whitespace | Good layouts; minor spacing issues | Basic layouts work | Layout breaks or looks cramped | ### Interactivity and JavaScript (20%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | JavaScript functionality | Multiple interactive features working well | At least one feature working well | Basic interactivity present | JavaScript errors or non-functional | | Code quality | Clean, well-organised code; uses const/let | Mostly clean; minor issues | Functional but messy | Disorganised or copied without understanding | | Progressive enhancement | Site fully works without JS | Core content works without JS | Some functionality lost without JS | Site unusable without JS | ### API Integration (15%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Implementation | API data displayed meaningfully; adds value | API working; reasonable use | API works but minimal value | API not working or missing | | Error handling | Loading states, error messages, graceful fallbacks | Loading and error states present | Some error handling | No error handling | ### Accessibility and Best Practices (10%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Accessibility | Keyboard navigable; good contrast; alt text; ARIA where needed | Most accessibility basics met | Some accessibility consideration | Major accessibility barriers | | Performance | Fast loading; optimised images | Reasonable performance | Some performance issues | Slow or bloated | ### AI Collaboration and Reflection (10%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Collaboration log | Detailed log showing critical engagement; modifications documented | Good documentation; shows thinking | Basic log with limited reflection | Missing or superficial log | | Reflection | Insightful reflection on process and learning | Good reflection on key learnings | Basic reflection | Missing or generic reflection | ## Submission Checklist Before submitting, verify: Technical - [ ] Live URL works and all pages/sections accessible - [ ] Site works on mobile, tablet, and desktop - [ ] No JavaScript errors in console - [ ] API integration functioning - [ ] HTML validates (W3C Validator) - [ ] Git repository has meaningful commit history Content - [ ] All required sections present (Home, About, Projects, Contact) - [ ] Content is professional and represents you well - [ ] Images have alt text - [ ] No placeholder or lorem ipsum text Documentation - [ ] AI collaboration log complete - [ ] Reflection document (500-750 words) covering: - Your development process - Challenges encountered and how you solved them - What you learned - How AI collaboration helped (or didn't) - What you would do differently ## What to Submit 1. Live URL: Where your portfolio can be viewed 2. Repository URL: Your GitHub (or similar) repository 3. AI collaboration log: Document (PDF or Markdown) 4. Reflection: 500-750 word document ## Getting Started Begin with these conversations with your AI partner: Remember: This portfolio is yours. AI can help you build it, but your decisions, your content, and your professional identity should drive it. You're the architect. ## Common Pitfalls to Avoid 1. Over-designing: Simple and professional beats flashy and distracting 2. Under-writing: "Check out my projects" tells employers nothing; explain what you did and learned 3. Ignoring mobile: Test on actual devices, not just browser resize 4. Forgetting accessibility: Keyboard navigation, colour contrast, alt text 5. Copying AI output blindly: If you can't explain it, you shouldn't submit it 6. Leaving console errors: Always check the browser console 7. Placeholder content: "Lorem ipsum" signals incompleteness ## After Submission Your portfolio is a living document. After this project: - Update it as you complete new work - Refine based on feedback - Keep the code clean and the content current The best portfolios evolve. This submission is the beginning, not the end. ============================================================ SOURCE: chapters/chapter-why-cms.qmd ============================================================ # Why CMS? The Business Value of Managed Content ## The Concept First In Part I, you built websites by writing code. Every heading, every paragraph, every image—you placed them precisely where they belonged. You had complete control. But here's the business reality: most websites need regular content updates, and most content updates shouldn't require a developer. Consider a small business website. The owner wants to: - Add a new service offering next week - Update prices when costs change - Post news about an upcoming event - Change the phone number when they move offices If every change requires editing HTML files and redeploying, that business has a problem. They either pay a developer for simple updates or let their site become stale. A Content Management System (CMS) solves this by separating content from code. The developer builds the structure and design once. Then, the business owner—without touching code—can create, edit, and publish content through a friendly interface. This isn't a technical convenience. It's a business architecture decision that affects costs, maintenance, and who controls what. ## Understanding Through Roles Think about how a newspaper works: - Journalists write articles. They focus on content quality, not page layout. - Editors review and approve content before publication. - Designers create the newspaper's visual templates and structure. - Printers produce the physical paper at scale. Each role has expertise. Each focuses on their domain. The journalist doesn't need to understand printing presses; they need a system that accepts their article and handles everything else. A CMS creates similar role separation for websites: - Content creators write and manage content through an interface - Administrators control permissions, workflows, and settings - Developers build themes, extend functionality, and handle technical concerns - Visitors see the published result The magic is that content creators never see code. Developers rarely touch content. Each role works in their comfort zone, and the system coordinates. ## The Handoff Test A website is truly "done" when you can hand it to the client and they can manage their own content. If they need to call a developer for every text change, the project succeeded technically but failed practically. ## Discovering CMS Concepts with Your AI Partner ### Exploration 1: Build vs Buy When should a business build a custom-coded site versus use a CMS? This is a foundational business decision. This conversation should reveal that CMS becomes increasingly valuable as: - Content updates become more frequent - More non-technical people need to contribute - The site needs to scale without developer intervention - Long-term maintenance costs matter Follow up: ### Exploration 2: Stakeholder Perspectives Different people care about different things. Understanding stakeholder needs is essential for recommending solutions. Stakeholders typically include: - Business owner (wants control, worries about costs) - Marketing team (wants easy publishing, worries about limitations) - IT/Developer (wants maintainability, worries about security) - End users (want good experience, don't care how it's built) ### Exploration 3: Content Strategy First Technology should serve content, not the other way around. Content strategy asks: What content do we need? Who creates it? How is it organised? This should reveal that technology decisions come after understanding: - What content types exist (pages, posts, products, events) - Who creates and approves content - How often content changes - How content relates to business goals ## From Concept to Code (Understanding CMS Architecture) While this chapter focuses on concepts, let's understand what a CMS actually does technically. ### The Core Separation Without a CMS: With a CMS: The CMS combines content from a database with design templates to generate the HTML that browsers display. Change the content in the database, and the generated HTML changes—without touching any code. ### CMS Types Not all CMSs work the same way: Traditional CMS (Coupled) - Content management and website delivery are one system - Examples: WordPress, Drupal, Joomla - Good for: Standard websites, blogs, small-medium businesses - The CMS generates and serves the web pages Headless CMS (Decoupled) - Content management is separate from content delivery - Content is accessed via API, displayed by a separate frontend - Examples: Contentful, Strapi, Sanity - Good for: Multi-channel content (web, mobile, kiosk), developer-led projects - We'll explore this in Website Builders (All-in-one) - Simplified CMS with built-in design tools - Examples: Squarespace, Wix, Webflow - Good for: Simple sites, non-technical users, quick launches - Limited flexibility but minimal technical requirement ### WordPress: The Dominant CMS WordPress powers over 40% of all websites. That's not a typo—nearly half of the web runs on this one platform. Why? Because it hits a sweet spot: - Free and open source: No licensing costs - Massive ecosystem: Thousands of themes and plugins - Flexible: Blogs, business sites, e-commerce, anything - Accessible: Non-developers can manage content - Extensible: Developers can customise deeply We'll spend Chapters 6-8 learning WordPress properly—not just how to use it, but how to evaluate it professionally and extend it when needed. ### The CMS Decision Framework When evaluating whether a project needs a CMS: | Factor | Suggests CMS | Suggests Custom Code | |--------|-------------|---------------------| | Content updates | Frequent (weekly+) | Rare (yearly) | | Content editors | Non-technical staff | Developers only | | Content volume | Growing over time | Fixed/static | | Budget for updates | Limited ongoing budget | Developer always available | | Time to launch | Faster with templates | Longer but fully custom | | Unique requirements | Standard patterns work | Highly unusual needs | ## Building Your Mental Model ### Content as Structured Data In a CMS, content isn't just text—it's structured data with defined fields: This structure enables: - Consistent presentation (every post has the same fields) - Searchability (find all posts by author) - Relationships (posts belong to categories) - Validation (required fields must be filled) ### The Template Layer Templates define how structured content becomes visual HTML: The template pulls fields from the content and arranges them. Change the template, and every post's appearance changes. Change one post's content, and only that post changes. This separation is powerful: designers work on templates, writers work on content, neither needs to understand the other's domain. ### The Permission Layer CMSs control who can do what: - Administrator: Full access to everything - Editor: Can manage all content but not settings - Author: Can write and publish their own content - Contributor: Can write but not publish (needs approval) These roles prevent accidents ("The intern deleted the homepage") and enable workflows ("All posts need editor approval before publishing"). ## Business Applications ### Client Handoff The true measure of a successful website project isn't launch day—it's whether the client can maintain it independently. A CMS-based site can be handed off with training: "Here's how you add a new blog post. Here's how you update your hours. Here's how you add a team member." Custom-coded sites often create ongoing dependency. ### Reduced Maintenance Costs Every developer-required change has a cost. With a CMS: - Content changes: Client handles directly ($0) - Design tweaks: Occasional developer work - Major features: Developer project Without a CMS: - Content changes: Developer required ($$$) - Everything requires technical involvement Over years, this difference compounds significantly. ### Content Governance For organisations with multiple content contributors, governance matters: - Who can publish without approval? - Who reviews content before it goes live? - Who can delete pages? - Who can access sensitive sections? A CMS with proper roles and workflows provides this structure. Custom code rarely includes such considerations. ### Scalability Need to add 50 new product pages? With a CMS: 1. Create a "Product" content type with appropriate fields 2. Content team adds 50 products through the interface 3. Products appear on the site automatically Without a CMS: a developer writes and deploys 50 pages of HTML. ## ULO Connection This develops ULO 3 (translating stakeholder needs into technical requirements) and ULO 4 (selecting appropriate technologies). Recommending a CMS isn't a technical decision—it's understanding who needs to do what and choosing architecture accordingly. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 5.1: CMS Identification (Level 1) Visit five local business websites. For each: 1. Try to identify if they're using a CMS (check for `/wp-admin/`, `?p=123` URLs, or use tools like BuiltWith) 2. If CMS, which one? 3. Does the site appear actively maintained? Document your findings. What patterns do you notice about businesses that use CMS versus those that don't? ### Exercise 5.2: Stakeholder Analysis (Level 2) For a hypothetical dental practice website, identify: 1. All stakeholders (beyond just the dentist) 2. What each stakeholder needs from the website 3. What each stakeholder would need to be able to do themselves 4. Potential conflicts between stakeholder needs Create a stakeholder matrix mapping needs to CMS requirements. ### Exercise 5.3: Content Audit (Level 3) Choose a small business website (could be a local business or a fictional scenario). Conduct a content audit: 1. List every content type on the site (pages, posts, products, etc.) 2. For each type, define the fields it would need 3. Estimate how often each content type changes 4. Identify who would likely update each type Based on your audit, would you recommend a CMS? Why or why not? ### Exercise 5.4: CMS Recommendation (Level 4) A boutique fitness studio approaches you. They want a website with: - Class schedules (change weekly) - Instructor profiles (change occasionally) - Pricing information (change quarterly) - Blog posts about fitness tips (new posts monthly) - Photo gallery (updated after events) The owner is comfortable with computers but not technical. Budget is moderate. They want to manage most updates themselves. Write a 300-word recommendation addressing: - Whether they need a CMS - What type of CMS would suit them - What content types you'd create - What the client could manage versus what needs developer involvement ### Exercise 5.5: Build vs Buy Analysis (Level 5) A tech startup wants a unique, highly interactive product landing page with animated demonstrations, custom calculators, and unusual layouts. They update content quarterly and have developers on staff. Another client, a law firm, wants a professional site with attorney profiles, practice areas, blog, and contact forms. They update content weekly and have no technical staff. For each: 1. Argue the case for using a CMS 2. Argue the case against using a CMS 3. Make and defend your recommendation This exercise has no single correct answer—develop your ability to weigh trade-offs and justify decisions (ULO 4). ## Chapter Summary - A CMS separates content from code, enabling non-technical users to manage websites - The decision to use a CMS is a business architecture decision, not just a technical one - Different stakeholders have different needs; CMS choice should balance these - Content strategy (what content, who creates it, how often it changes) precedes technology choice - WordPress dominates the CMS market due to its flexibility, ecosystem, and accessibility - Role-based permissions enable content governance and workflow control ## Reflection Before moving to Chapter 6, ensure you can: - [ ] Explain what a CMS does without using technical jargon - [ ] Identify when a project would benefit from a CMS versus custom development - [ ] List at least three different stakeholder roles and their CMS-related needs - [ ] Describe the difference between traditional and headless CMS - [ ] Explain why WordPress is so widely used - [ ] Articulate the long-term cost implications of CMS versus custom code ## Your Learning Journal Record your responses to these prompts: 1. CMS Encounters: Think about websites you use regularly. Which are clearly CMS-powered? How can you tell? What does this suggest about when CMS makes sense? 2. Stakeholder Empathy: Put yourself in the shoes of a non-technical business owner. What would frustrate you about needing to contact a developer for every content change? What would you want from a content management interface? 3. AI Conversation Reflection: What question about CMS selection did your AI partner help clarify? What factors hadn't you considered before the conversation? 4. Business Thinking: How does thinking about "who updates what" change how you approach web projects? Why might this question be more important than "what technology should we use"? ## Next Steps You now understand why CMS matters and when to use one. In , we'll dive deep into WordPress—not as a blogging tool, but as a professional platform. We'll set up a local development environment, understand WordPress's architecture, and learn to evaluate it critically. This isn't about clicking through menus—it's about understanding a platform that powers nearly half the web and knowing when it's the right (or wrong) choice for a project. ============================================================ SOURCE: chapters/chapter-wordpress-platform.qmd ============================================================ # WordPress as Platform ## The Concept First WordPress powers over 40% of the web. That's an extraordinary number—nearly half of all websites run on a single platform. Understanding why reveals something important about how technology decisions are made in business. WordPress isn't just "blogging software." It's a platform—a foundation that others build upon. The distinction matters: - Software does specific things. You use it as-is. - A platform provides a foundation. An ecosystem builds on top of it. Your smartphone is a platform. The core provides basics (calls, settings), but the app ecosystem makes it powerful. You don't judge your phone by its built-in apps alone—you judge it by what you can do with the apps others have built. WordPress works the same way. The core handles content management. Themes control appearance. Plugins add functionality. The ecosystem—over 60,000 plugins, thousands of themes—is what makes WordPress suitable for almost any website. Learning WordPress means learning to evaluate and assemble these pieces professionally. ## Understanding Through Ecosystems Imagine opening a restaurant. You could: Option A: Build everything from scratch. Design your own stoves, create your own recipes, invent your own point-of-sale system. Option B: Use standard commercial kitchen equipment, adapt proven recipes, install established POS software, then focus your creativity on your unique menu and dining experience. Option B gets you open faster, with tested components, and lets you focus on what makes your restaurant special. This is platform thinking. WordPress provides the kitchen equipment. Themes provide the interior design. Plugins provide specialised tools (reservation systems, online ordering). You focus on your content and business logic. ## The Platform Evaluation Question When evaluating any platform, ask: "How active is the ecosystem?" A platform with a dying ecosystem becomes a liability. WordPress's ecosystem is massive and active—a significant factor in its dominance. ## Discovering WordPress with Your AI Partner ### Exploration 1: Platform vs Software Let's clarify the distinction between platforms and ordinary software: This should reveal characteristics of platforms: - Third parties build on them - An ecosystem of extensions exists - The value increases as the ecosystem grows - Users can customise without changing the core ### Exploration 2: Theme and Plugin Evaluation The WordPress ecosystem contains gems and garbage. Professional evaluation skills are essential: Quality signals include: - Active development (recent updates) - Large install base with good reviews - Responsive support - Clean code (if you can inspect it) - Clear documentation Red flags include: - No updates in over a year - Few installations despite being old - Poor reviews mentioning security or support - Abandoned by developer - Excessive permission requests ### Exploration 3: WordPress Architecture Understanding how WordPress is built helps with troubleshooting and customisation: A typical analogy might map: - Database = Storage (pantry, inventory, recipes) - Core = Kitchen operations (combining ingredients into dishes) - Themes = Dining room design (how food is presented) - Plugins = Specialised equipment (espresso machine, wine fridge) ## From Concept to Code Let's set up WordPress locally and understand its core components. ### Local Development with LocalWP Never develop directly on a live website. Local development means: - You can experiment without breaking anything - You don't need internet access - Changes are instant (no upload time) - You can test risky changes safely LocalWP (formerly Local by Flywheel) is the simplest way to run WordPress locally: 1. Download from localwp.com 2. Install and open 3. Click "Create a new site" 4. Choose a name, username, and password 5. Wait for setup to complete That's it. You now have a WordPress site running on your computer. LocalWP handles the complexity—PHP, MySQL, web server—behind a simple interface. ## Alternatives Other local development options include XAMPP, MAMP, and Docker-based setups. LocalWP is recommended for beginners because it's WordPress-specific and handles configuration automatically. ### The WordPress Admin Interface Click "WP Admin" in LocalWP to access your site's dashboard. This is the content management interface—where non-developers spend their time. Dashboard Areas: | Area | Purpose | |------|---------| | Dashboard | Overview and quick actions | | Posts | Blog posts and news | | Media | Images, files, uploads | | Pages | Static pages (About, Contact) | | Comments | Reader comments (if enabled) | | Appearance | Themes, menus, widgets | | Plugins | Add functionality | | Users | Account management | | Settings | Site configuration | Spend time exploring each area. Understanding the admin interface is essential—this is what you'll train clients to use. ### Posts vs Pages WordPress has two main content types by default: Posts are: - Time-based (have publish dates) - Categorised and tagged - Appear in feeds and archives - Good for: Blog articles, news, updates Pages are: - Timeless (no dates emphasised) - Hierarchical (can have parent pages) - Not categorised - Good for: About, Contact, Services, static content The distinction isn't technical capability—it's organisational. Posts answer "What's new?" Pages answer "What do we do?" ### Understanding Themes A WordPress theme controls: - Visual appearance (colours, fonts, layout) - Template structure (what appears where) - Available features (some themes add functionality) The theme doesn't contain your content—it presents your content. Change themes, and content remains while appearance transforms. Exploring Themes: 1. Go to Appearance → Themes 2. Click "Add New" 3. Browse featured, popular, or search for specific needs 4. Use "Live Preview" to see a theme with your content 5. Activate when ready Theme Evaluation Criteria: | Factor | Questions to Ask | |--------|-----------------| | Purpose fit | Is this designed for sites like yours? | | Responsiveness | Does it work well on mobile? | | Speed | Is it lightweight or bloated? | | Customisation | Can you change colours/fonts without code? | | Updates | Is it actively maintained? | | Reviews | What do other users say? | | Support | Can you get help if needed? | ### The Template Hierarchy WordPress uses a template hierarchy to determine which template file displays content. Understanding this helps when you need to customise. WordPress looks for the most specific template first, falling back to more general ones. This allows themes to have special templates for specific pages while using defaults for everything else. ### Basic Customisation Most modern themes include a Customiser (Appearance → Customise) for no-code adjustments: - Site identity (logo, tagline) - Colours - Typography (some themes) - Header/footer layout - Homepage settings - Menus The Customiser shows live previews—experiment freely before publishing changes. Menus: 1. Appearance → Menus 2. Create a new menu 3. Add pages, posts, custom links, or categories 4. Arrange by dragging 5. Assign to a theme location (Primary, Footer, etc.) Widgets (if your theme uses them): 1. Appearance → Widgets 2. Drag widgets to sidebar/footer areas 3. Configure each widget's settings ### Settings That Matter In Settings, pay attention to: General: - Site Title and Tagline (appears in browser tabs, search results) - Timezone (affects scheduled posts) Reading: - Homepage displays: Latest posts vs. static page - Posts per page Permalinks: - URL structure: Choose "Post name" for clean URLs (`/about/` instead of `/?p=123`) - Change this early—changing later breaks existing links Discussion: - Comment settings (enable/disable, moderation rules) ## Building Your Mental Model ### The WordPress Stack When something goes wrong, think through these layers: - Display issue? Probably theme - Feature not working? Probably plugin - General malfunction? Possibly core or server - Can't log in? Database or user settings ### Content Separation A key mental model: content lives in the database, presentation lives in the theme. This separation is why you can change themes without losing content. ### The Hook System WordPress allows code to "hook" into specific points in the execution flow. While you won't write hooks yet, understanding they exist explains how plugins modify WordPress without changing core files: - Plugins register functions to run at specific points - WordPress calls these functions when reaching those points - Multiple plugins can hook into the same point This architecture is why WordPress is extensible without modification—a key platform characteristic. ## Business Applications ### Market Demand WordPress skills are in demand. Whether freelancing, agency work, or in-house roles, WordPress knowledge is marketable because: - Huge market share means abundant projects - Businesses have existing WordPress sites needing maintenance - Lower barrier to entry than custom development - Clients often specifically request WordPress ### Cost Structure For clients, WordPress offers: - No licensing fees (open source) - Lower development costs (existing ecosystem) - Reduced maintenance costs (client self-service) - Lower switching costs (many developers available) ### Flexibility The plugin ecosystem means you rarely need custom development: - E-commerce: WooCommerce - Forms: Gravity Forms, WPForms, Contact Form 7 - SEO: Yoast, RankMath - Security: Wordfence, Sucuri - Backup: UpdraftPlus, VaultPress - Caching: WP Super Cache, W3 Total Cache Often, the professional skill is knowing which plugins to combine—not building from scratch. ### When WordPress Isn't Right Professional judgment includes knowing when not to use WordPress: - Highly custom web applications (better: custom framework) - Real-time features (better: specialised platforms) - Very simple one-page sites (better: static HTML or website builders) - Maximum performance requirements (better: headless architecture) ## ULO Connection This develops ULO 4 (making and defending technology choices) and ULO 5 (evaluating technologies). Choosing WordPress requires evaluating its ecosystem, understanding its architecture, and articulating why it's appropriate (or not) for specific situations. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 6.1: Local Setup (Level 1) Install LocalWP and create a WordPress site called "Practice Site": 1. Document the process with screenshots 2. Log into the admin dashboard 3. Create one page and one post 4. Change the permalink structure to "Post name" 5. Upload an image to the Media Library Verify everything works by viewing the site in your browser. ### Exercise 6.2: Theme Exploration (Level 2) Using your Practice Site: 1. Install and preview three different free themes 2. For each theme, document: - What kind of site it seems designed for - What customisation options it offers - How it handles responsiveness (test at different sizes) 3. Choose one and activate it 4. Use the Customiser to adjust site identity and colours ### Exercise 6.3: Content Structure (Level 3) Create content for a fictional coffee shop on your Practice Site: 1. Create pages: Home, About, Menu, Contact 2. Create a menu in Appearance → Menus and assign it 3. Set the homepage to display a static page 4. Create three blog posts about coffee (news, events, tips) 5. Assign the posts to categories you create Evaluate: Is the content discoverable? Can a visitor navigate easily? ### Exercise 6.4: Theme Evaluation Report (Level 4) Research three WordPress themes suitable for a professional services business (lawyer, accountant, consultant). For each: 1. Document key features 2. Check last update date and developer responsiveness 3. Read at least 5 reviews 4. Test the demo for mobile responsiveness 5. Identify potential limitations Write a 400-word recommendation explaining which theme you'd choose and why. Discuss trade-offs. ### Exercise 6.5: Platform Comparison (Level 5) A client asks: "Should I use WordPress or Squarespace for my boutique hotel website?" Research both platforms and write a balanced comparison (500 words) addressing: 1. Cost (initial and ongoing) 2. Ease of use for the client 3. Design flexibility 4. Booking system integration options 5. Long-term maintenance considerations 6. Your recommendation with justification This exercise develops technology evaluation skills (ULO 5). ## Chapter Summary - WordPress is a platform, not just software—its ecosystem is its value - Professional evaluation of themes and plugins is an essential skill - Local development with LocalWP provides a safe environment to learn - Understanding WordPress architecture (core, themes, plugins, database) aids troubleshooting - The template hierarchy determines which template displays content - WordPress isn't always the right choice—professional judgment matters ## Reflection Before moving to Chapter 7, ensure you can: - [ ] Explain the difference between a platform and software - [ ] Set up WordPress locally using LocalWP - [ ] Navigate the WordPress admin interface confidently - [ ] Explain the difference between posts and pages - [ ] Evaluate a theme's quality using specific criteria - [ ] Describe how the template hierarchy works - [ ] Articulate when WordPress is and isn't appropriate ## Your Learning Journal Record your responses to these prompts: 1. Platform Thinking: What other platforms do you use daily? What makes their ecosystems valuable? How does this inform your understanding of WordPress? 2. Theme Exploration: What surprised you when exploring WordPress themes? What features seem most valuable for business sites? 3. AI Conversation Reflection: What question about WordPress architecture or evaluation did your AI partner help clarify? 4. Professional Judgment: If a client asked why they shouldn't just use Wix, how would you respond? When would Wix be the better choice? ## Next Steps You now understand WordPress as a platform and can set up and configure a basic site. In , we'll explore how to extend WordPress with plugins—both using existing plugins professionally and understanding how they work. This knowledge is essential for customising WordPress to meet specific business requirements without starting from scratch. ============================================================ SOURCE: chapters/chapter-extending-platforms.qmd ============================================================ # Extending Platforms ## The Concept First In , you learned that WordPress's value lies in its ecosystem. Now we'll learn to extend WordPress professionally—using plugins wisely, customising safely, and making business decisions about when to build versus when to buy. Here's the tension: plugins make WordPress powerful, but plugins also create risk. Every plugin you add: - Depends on someone else maintaining it - Could conflict with other plugins - Might introduce security vulnerabilities - Adds complexity to troubleshoot Professional WordPress development isn't about installing the most plugins—it's about installing the right plugins and knowing when custom development makes more sense. ## Understanding Through Build vs Buy Every feature request presents a choice: Buy (Use existing plugin): - Faster to implement - Someone else maintains it - Battle-tested by thousands of users - May not fit exact requirements Build (Custom development): - Exact fit for requirements - You control maintenance - No dependency on external developers - Higher upfront cost Neither is always better. The professional skill is evaluating trade-offs. Consider a business that needs a booking system: | Factor | Plugin (e.g., Bookly) | Custom Build | |--------|----------------------|--------------| | Implementation time | Hours | Weeks | | Upfront cost | $0-300 | $5,000-20,000 | | Fits requirements | 80-90% | 100% | | Ongoing updates | Plugin developer | You | | Customisation | Limited | Unlimited | | Risk of abandonment | Medium | None (you own it) | For most small businesses, the plugin wins. For a booking-centric business with unique requirements, custom might justify its cost. ## The 80% Rule If an existing solution meets 80% of requirements, adapting workflows to fit the tool often costs less than building the remaining 20% custom. Perfect fit isn't always worth the price. ## Discovering Extensions with Your AI Partner ### Exploration 1: Plugin Evaluation Framework When multiple plugins solve the same problem, how do you choose? Your evaluation framework should include: - Feature match to requirements - Ease of use (for you and the client) - Performance impact - Price (free vs. premium features) - Support and documentation - Update frequency and developer reputation - Integration with other tools ### Exploration 2: Build vs Buy Decision Let's work through a realistic scenario: This conversation should reveal: - Volume of bookings (justifies complexity) - Unique requirements (standard vs. unusual workflows) - Integration needs (payment, email, calendars) - Budget reality (short-term vs. long-term costs) - Client technical capacity (who maintains this?) ### Exploration 3: Technical Debt Plugins have hidden costs: Technical debt accumulates when: - Plugins conflict with each other - Updates break functionality - Performance degrades - Security vulnerabilities compound - Nobody understands all the pieces ### Exploration 4: AI-Assisted WordPress Development AI is particularly effective at writing WordPress PHP code: This conversation should demonstrate: - How to structure requests for WordPress PHP code - The importance of asking for explanations, not just code - How filters modify content in WordPress - Testing approach for custom PHP ## From Concept to Code Let's learn to extend WordPress professionally. ### Installing and Managing Plugins Installing from the repository: 1. Plugins → Add New 2. Search for the plugin 3. Click "Install Now" 4. Click "Activate" Installing premium plugins: 1. Download the .zip file from the vendor 2. Plugins → Add New → Upload Plugin 3. Select the .zip file 4. Install and activate Managing plugins: - Deactivate plugins you're not using (don't just leave them inactive—delete them) - Update plugins regularly (but test first on staging) - Document why each plugin is installed - Review plugins quarterly—needs change ### Essential Plugin Categories Most business WordPress sites need plugins in these categories: Security: - Wordfence or Sucuri: Firewall, malware scanning, login protection - Essential—WordPress is a common target Backup: - UpdraftPlus: Scheduled backups to cloud storage - Non-negotiable—databases get corrupted, hosts fail Performance: - WP Super Cache or W3 Total Cache: Page caching - Smush or ShortPixel: Image optimisation - Noticeable impact on user experience and SEO SEO: - Yoast SEO or RankMath: Meta tags, sitemaps, readability - Important for discoverability Forms: - WPForms, Gravity Forms, or Contact Form 7 - Nearly every site needs contact forms ### Evaluating Plugin Quality Before installing any plugin, check: In the repository listing: - Last updated (within 3-6 months) - Active installations (higher = more tested) - WordPress version compatibility - Star rating and reviews (read the negative ones) - Support forum activity (does developer respond?) In reviews, watch for: - Security issues mentioned - Conflicts with common plugins/themes - Broken updates - Abandoned development - Excessive resource usage Test before deploying: - Install on a staging site first - Test core functionality - Check for conflicts with existing plugins - Monitor performance impact ### Plugin Conflicts Plugins can conflict because they: - Modify the same functionality - Use incompatible JavaScript libraries - Compete for database resources - Override the same hooks Diagnosing conflicts: 1. Note the symptoms (error messages, broken features) 2. Deactivate all plugins 3. Reactivate one by one, testing each time 4. Identify the conflicting combination 5. Decide: replace one, find alternative, or contact support Preventing conflicts: - Minimise plugin count (each one adds risk) - Choose well-maintained plugins - Test updates on staging first - Keep WordPress core updated ### Child Themes: Safe Customisation If you modify a theme directly, your changes disappear when the theme updates. Child themes solve this. A child theme: - Inherits everything from the parent theme - Lets you override specific files - Preserves your changes through parent theme updates Creating a child theme: 1. Create a folder in `/wp-content/themes/` named `{parent-theme}-child` 2. Create `style.css` with required headers: 3. Create `functions.php` to enqueue parent styles: 4. Activate the child theme in Appearance → Themes Now any CSS you add to the child's `style.css` applies on top of the parent, and any template files you create in the child override the parent's versions. ### Functions.php: Small Customisations For small code customisations, the child theme's `functions.php` is appropriate: ## functions.php Caution Syntax errors in functions.php can break your entire site. Test on staging, and consider a plugin like Code Snippets that isolates code pieces and lets you disable them if they cause problems. ### PHP Fundamentals for WordPress WordPress is built on PHP. While you can accomplish a lot without writing PHP, understanding the basics opens up powerful customisation options—and AI is excellent at helping you write WordPress PHP code. PHP basics: PHP code runs on the server and generates HTML sent to the browser. PHP files mix HTML and PHP: Key PHP concepts: ### WordPress Template Tags WordPress provides functions (called "template tags") that output common elements: ### The WordPress Loop The Loop is how WordPress displays posts. It's the core pattern you'll see in every theme: Understanding this pattern helps you customise how posts display. ### Hooks: Actions and Filters WordPress uses "hooks" to let you modify behaviour without editing core files. There are two types: Actions – Do something at a specific point: Filters – Modify data before it's used: ### Building a Simple Plugin with AI AI excels at writing WordPress plugins. Here's how to approach it: Example: A plugin to display business hours AI might generate something like: To install this plugin: 1. Create a folder `simple-business-hours` in `/wp-content/plugins/` 2. Save the code as `simple-business-hours.php` in that folder 3. Activate in Plugins → Installed Plugins 4. Configure in Settings → Business Hours 5. Use `[business_hours]` shortcode in any page ## AI Plugin Development When asking AI to write WordPress plugins: 1. Be specific about functionality 2. Request comments explaining the code 3. Test thoroughly on a staging site 4. Review the code—understand what it does before installing 5. Ask AI to explain any parts you don't understand ### Customising Theme Templates You can override any parent theme template by copying it to your child theme and modifying it. Common templates to customise: | Template | Purpose | |----------|---------| | `header.php` | Site header, navigation | | `footer.php` | Site footer | | `single.php` | Single blog post | | `page.php` | Individual pages | | `archive.php` | Post listing pages | | `functions.php` | Theme functions | Example: Custom single post template Copy `single.php` from parent theme to child theme, then modify: ### When to Build Custom Consider custom development when: - No plugin meets the core requirement - Plugins would require heavy modification anyway - The feature is central to the business model - Security or performance requirements are extreme - Long-term cost of plugin licensing exceeds development Even then, consider: - A small custom plugin (focused, maintainable) - Modifying an existing plugin (with a child plugin approach) - Combining simpler plugins with custom glue code Full custom rarely means starting from zero. ## Building Your Mental Model ### The Extension Pyramid Start from the bottom: can WordPress core do it? Can a well-established free plugin do it? Only climb the pyramid when lower levels don't work. ### The Dependency Chain Every plugin creates a dependency: More plugins = more dependencies = more things that can break. ### The True Cost Formula When evaluating options: Over 5 years, the math often favours plugins for standard features. ## Business Applications ### ROI Calculation Present plugin decisions to clients in business terms: "A custom booking system would cost $15,000 to build and $2,000/year to maintain. The plugin costs $200/year. Over 5 years: - Custom: $15,000 + ($2,000 × 5) = $25,000 - Plugin: $200 × 5 = $1,000 The plugin doesn't do everything you want, but is that extra functionality worth $24,000?" ### Risk Communication Help clients understand risks: "This plugin has 500,000 active installations and is updated monthly. It's well-maintained. But if the developer stops working on it, we'd need to find an alternative. That's a risk with any plugin, which is why we document everything and maintain backups." ### Managing Expectations When clients want custom features: "We can definitely build that custom. But let me show you how three existing plugins handle similar needs. If any of these work for you, you'll save significant money and get something battle-tested by thousands of users." This positions you as an advisor, not just an implementer. ### Security Responsibility Plugins are the most common WordPress security vulnerability. Your role: - Evaluate plugin security before installation - Keep plugins updated - Monitor for vulnerability announcements - Have a response plan if something is compromised - Document which plugins are installed and why ## ULO Connection This develops ULO 4 (making and defending technology choices) and ULO 1 (evaluating effective solutions). Professional plugin decisions require balancing features, costs, risks, and long-term maintenance—exactly the judgment businesses need from technology advisors. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 7.1: Plugin Research (Level 1) On your local WordPress site: 1. Search for and compare three SEO plugins (e.g., Yoast, RankMath, All in One SEO) 2. For each, document: active installs, last updated, rating, key features 3. Install one and explore its settings 4. Write a brief summary of which you'd recommend and why ### Exercise 7.2: Create a Child Theme (Level 2) Create a child theme for your local site: 1. Follow the child theme creation process 2. Add custom CSS that changes the site's link colour 3. Verify the change appears 4. Confirm the parent theme still functions Document the process with screenshots. ### Exercise 7.3: PHP Customisation with AI (Level 3) Use AI to add a custom feature to your WordPress site: 1. Choose one of these features (or propose your own): - Display "Reading time: X minutes" above each post - Add a "Back to top" button that appears when scrolling - Show related posts at the end of each blog post - Add a custom greeting based on time of day in the header 2. Ask your AI to help you implement it in your child theme's functions.php 3. For the code AI provides: - Read through it and identify what each part does - Ask AI to explain anything you don't understand - Test it on your local site - Document what you learned 4. Write 200 words explaining: What did the code do? What PHP concepts were used? What would you modify? ### Exercise 7.4: Build a Plugin with AI (Level 4) Create a simple WordPress plugin using AI assistance: 1. Define a specific need (examples): - A "Coming Soon" banner for selected pages - Social media share buttons for posts - A shortcode that displays a styled call-to-action box - A widget that shows recent posts from a specific category 2. Ask AI to create the plugin, requesting comments that explain the code 3. Install and test the plugin on your local site 4. Document: - The prompts you used with AI - How you tested the plugin - Any modifications you made - What you learned about WordPress plugin structure ### Exercise 7.5: Plugin Audit (Level 3) Your local site probably has several plugins now. Conduct an audit: 1. List every installed plugin 2. For each, document: purpose, last update, whether it's essential 3. Identify any that could be removed 4. Identify any that should be replaced with better alternatives 5. Create a recommendation document ### Exercise 7.6: Build vs Buy Analysis (Level 4) A client needs an event calendar for their community centre. Events have dates, times, locations, descriptions, and categories. Visitors should be able to filter by category and view a monthly calendar. Research options and write a 400-word recommendation: 1. Identify two or three plugin options 2. Evaluate each against requirements 3. Consider what custom development would entail 4. Make a recommendation with justification 5. Address risks and mitigation ### Exercise 7.7: Extension Strategy (Level 5) You're taking over a WordPress site for a small marketing agency. They need: - Portfolio showcase - Team member profiles - Client testimonials - Contact forms - Blog - Newsletter signup Currently, they have 23 plugins installed, some of which seem redundant. Develop an extension strategy document (500 words): 1. What categories of plugins are essential? 2. How would you evaluate their current plugins? 3. What's your approach to consolidation? 4. How would you communicate changes to the client? 5. What ongoing maintenance would you recommend? This exercise develops professional consulting skills. ## Chapter Summary - Every extension decision weighs build vs. buy trade-offs - Plugin evaluation requires systematic criteria, not just feature lists - Child themes allow safe customisation that survives updates - PHP is WordPress's foundation—understanding basics enables deeper customisation - The Loop and hooks (actions/filters) are core WordPress patterns - AI excels at writing WordPress plugins and theme customisations - Technical debt from plugins accumulates silently - Professional judgment means recommending the right solution, not the most impressive one ## Reflection Before moving to Chapter 8, ensure you can: - [ ] Evaluate plugins using systematic criteria - [ ] Articulate build vs. buy trade-offs to a non-technical client - [ ] Create and use a child theme for customisation - [ ] Explain basic PHP syntax (variables, arrays, conditionals, loops) - [ ] Describe what the WordPress Loop does - [ ] Explain the difference between actions and filters - [ ] Use AI to help write simple WordPress plugins - [ ] Identify signs of a poorly maintained plugin - [ ] Explain technical debt in business terms ## Your Learning Journal Record your responses to these prompts: 1. Extension Audit: Look at a WordPress site you use or manage. How many plugins does it have? Do they all seem necessary? What would you consolidate? 2. Trade-off Thinking: Think of a feature request that could be solved by either plugin or custom development. What factors would tip your recommendation one way or the other? 3. AI Conversation Reflection: What question about plugin evaluation or build vs. buy decisions did your AI partner help clarify? 4. Professional Communication: How would you explain to a client why you're recommending a paid plugin instead of a free one? What value does the paid version provide? ## Next Steps You now know how to extend WordPress wisely with plugins and child themes. But there's another approach entirely: using WordPress as a content backend while building the frontend with modern tools. In , we'll explore headless WordPress—using the WordPress REST API to power a React frontend. This bridges your CMS knowledge with the modern frontend skills from Part III and represents how many larger organisations use WordPress today. ============================================================ SOURCE: chapters/chapter-headless-architecture.qmd ============================================================ # Headless Architecture ## The Concept First In previous chapters, WordPress handled everything: it stored content, managed users, and generated the HTML visitors see. The content management and the website delivery were one unified system. Headless architecture separates these concerns. WordPress becomes a content backend—storing and managing content—while a separate frontend application handles presentation. They communicate through APIs. Why would you do this? Because sometimes you want: - WordPress's excellent content management - A modern frontend built with React or other frameworks - Content delivered to multiple channels (web, mobile apps, kiosks) - The performance benefits of static or cached frontends - Complete design freedom unconstrained by WordPress themes This approach is increasingly common for larger projects, media companies, and organisations with sophisticated frontend needs. ## Understanding Through Separation Imagine a restaurant operation: Traditional restaurant (traditional WordPress): - Kitchen and dining room in one building - Chefs prepare food, servers deliver it directly - Simple, everything coordinated, but limited to that one location Central kitchen + multiple outlets (headless): - Central kitchen prepares food (WordPress manages content) - Multiple dining locations serve customers (web, mobile, etc.) - Food travels via delivery (API) - Each outlet can have different ambiance (different frontends) - Kitchen changes don't require redesigning dining rooms The central kitchen can supply a fine dining restaurant, a casual café, and a food truck—each with completely different presentations of the same underlying food. ## Headless = API-First "Headless" means the CMS has no "head"—no built-in frontend. It's all backend. Content exits only through APIs, and something else (the "head") must display it. ## Discovering Headless with Your AI Partner ### Exploration 1: Architecture Trade-offs Every architecture has trade-offs. Let's explore them: This should reveal: Traditional WordPress advantages: - Simpler to set up and maintain - Non-technical users can preview content - Huge ecosystem of themes - Lower technical barrier Headless advantages: - Frontend flexibility - Better performance potential - Multi-channel content delivery - Modern developer experience ### Exploration 2: APIs as Contracts The API is the contract between backend and frontend: The API contract specifies: - What endpoints exist (`/wp-json/wp/v2/posts`) - What data format to expect (JSON) - What parameters can be sent (filters, pagination) - What errors might occur Frontend developers can build against this contract without needing to understand PHP or WordPress internals. ### Exploration 3: Business Cases Where does headless make practical sense? Common scenarios include: - Media companies publishing to web, mobile apps, and smart devices - E-commerce with heavily customised, high-performance frontends - Organisations integrating content into existing applications - Sites requiring the fastest possible load times (static generation) ## From Concept to Code Let's explore the WordPress REST API and understand how to consume content from an external frontend. ### The WordPress REST API WordPress includes a built-in REST API. Every WordPress site (version 4.7+) automatically exposes content through standardised endpoints. Default endpoints: | Endpoint | Returns | |----------|---------| | `/wp-json/wp/v2/posts` | Blog posts | | `/wp-json/wp/v2/pages` | Pages | | `/wp-json/wp/v2/categories` | Categories | | `/wp-json/wp/v2/tags` | Tags | | `/wp-json/wp/v2/media` | Media items | | `/wp-json/wp/v2/users` | Users (public info) | Try it yourself: If your local WordPress site is running, visit `http://your-site.local/wp-json/wp/v2/posts` in your browser. You'll see JSON data for your posts. ### Fetching Posts from WordPress Using the JavaScript skills from : Each post object contains: Note: `title.rendered` and `content.rendered` contain the processed HTML, ready for display. ### Filtering and Pagination The API supports query parameters: Common parameters: | Parameter | Purpose | Example | |-----------|---------|---------| | `per_page` | Results per page (max 100) | `?per_page=10` | | `page` | Page number | `?page=2` | | `search` | Search term | `?search=recipe` | | `categories` | Filter by category ID | `?categories=5` | | `tags` | Filter by tag ID | `?tags=12` | | `orderby` | Sort field | `?orderby=title` | | `order` | Sort direction | `?order=asc` | | `_embed` | Include related data | `?_embed` | ### Getting Related Data with _embed By default, the API returns IDs for related content (like featured images). The `_embed` parameter includes that data directly: The embedded data appears in `_embedded`: ### A Complete Example: Displaying Posts Let's build a simple frontend that displays WordPress posts: ```html Headless Blog .post-card { border: 1px solid #ddd; padding: 1rem; margin-bottom: 1rem; border-radius: 4px; } .post-card h2 { margin-top: 0; } .loading, .error { padding: 1rem; text-align: center; } .error { color: red; } Latest Posts Loading posts... async function loadPosts() { const container = document.querySelector('#posts-container'); try { const response = await fetch( 'http://your-site.local/wp-json/wp/v2/posts?_embed&per_page=5' ); if (!response.ok) { throw new Error(`HTTP error: ${response.status}`); } const posts = await response.json(); // Clear loading message container.innerHTML = ''; // Render each post posts.forEach(post => { const card = document.createElement('article'); card.classList.add('post-card'); // Get featured image if available const featuredImage = post._embedded?.['wp:featuredmedia']?.[0]; const imageHtml = featuredImage ? `` : ''; card.innerHTML = ` ${imageHtml} ${post.title.rendered} ${post.excerpt.rendered} Read more `; container.appendChild(card); }); } catch (error) { container.innerHTML = ` Failed to load posts: ${error.message} `; console.error('Error loading posts:', error); } } loadPosts(); Ask your AI: Walk me through this code. What happens at each step? How would I modify it to also show the post date and author name? javascript // By ID fetch('/wp-json/wp/v2/posts/42') // By slug fetch('/wp-json/wp/v2/posts?slug=welcome-to-our-blog') php // Register custom post type with REST API support register_post_type('product', array( 'public' => true, 'show_in_rest' => true, // This exposes it to the API 'rest_base' => 'products', // Endpoint: /wp-json/wp/v2/products // ... other arguments )); javascript fetch('/wp-json/wp/v2/products?_embed') javascript const credentials = btoa('username:application-password'); fetch('/wp-json/wp/v2/posts', { headers: { 'Authorization': `Basic ${credentials}` } }); php // Allow CORS from specific origin add_action('rest_api_init', function() { remove_filter('rest_pre_serve_request', 'rest_send_cors_headers'); add_filter('rest_pre_serve_request', function($value) { header('Access-Control-Allow-Origin: https://your-frontend-domain.com'); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); header('Access-Control-Allow-Credentials: true'); return $value; }); }); ┌────────────────────────────────────────┐ │ WordPress │ │ ┌─────────────┐ ┌─────────────────┐ │ │ │ Content │──│ Theme │ │ │ │ Database │ │ (Presentation) │ │ │ └─────────────┘ └─────────────────┘ │ └───────────────────────────┬────────────┘ │ HTML ▼ Browser ┌──────────────────┐ ┌─────────────────┐ │ WordPress │ │ Frontend │ │ ┌────────────┐ │ API │ (React, etc.) │ │ │ Content │ │◄──────►│ │ │ │ Database │ │ JSON │ │ │ └────────────┘ │ └────────┬────────┘ └──────────────────┘ │ HTML ▼ Browser ``` In headless, WordPress's theming layer isn't used. It's purely a content repository. ### When Headless Makes Sense | Scenario | Why Headless? | |----------|---------------| | Multi-channel delivery | Same content to web, iOS app, Android app, smart displays | | Maximum performance | Static site generation, edge caching | | Complex frontend needs | Single-page applications, heavy JavaScript interactivity | | Developer preferences | Modern frontend frameworks, component architecture | | Integration requirements | Content feeds into existing applications | ### When Traditional Makes Sense | Scenario | Why Traditional? | |----------|------------------| | Content editors need preview | See exactly what's published | | Simple sites | Blog, brochure site, small business | | Limited technical resources | No frontend developers available | | Plugin-dependent features | Many plugins expect traditional setup | | Budget constraints | Two systems cost more to maintain | ### The Complexity Cost Headless adds complexity: - Two codebases instead of one - Two deployments to manage - Content preview is harder - Some WordPress plugins don't work - More technical expertise required This complexity has costs. Headless is a tool—use it when benefits outweigh costs. ## Business Applications ### Multi-Channel Content Organisations increasingly need content everywhere: - Corporate website - Mobile applications - Internal dashboards - Digital signage - Partner integrations With headless, content is created once and consumed everywhere. WordPress becomes the "single source of truth." ### Performance and SEO Headless frontends can be: - Statically generated (fastest possible) - Cached at the edge (CDN) - Optimised specifically for performance This matters for SEO and user experience—Google measures page speed. ### Security Benefits In headless architecture: - WordPress can be hidden from the public (private network) - Attack surface is reduced - Frontend has no direct database access - Compromising the frontend doesn't compromise content For high-security needs, this separation is valuable. ### Developer Experience Modern frontend developers often prefer: - React, Vue, or similar frameworks - Component-based architecture - TypeScript - Modern build tools Headless lets them use their preferred tools while leveraging WordPress's content management. ## ULO Connection This develops ULO 4 (selecting appropriate technologies) and ULO 5 (evaluating emerging approaches). Headless architecture is a significant trend in web development. Understanding when it applies—and when it doesn't—demonstrates professional judgment. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 8.1: Explore the API (Level 1) Using your local WordPress site: 1. Open a browser and visit `/wp-json/wp/v2/posts` 2. Explore the JSON structure—identify title, content, date, and other fields 3. Try different endpoints: `/pages`, `/categories`, `/media` 4. Add `?_embed` and observe how the response changes Document your findings with screenshots. ### Exercise 8.2: Build a Post List (Level 2) Create an HTML page that: 1. Fetches the 3 most recent posts from your WordPress site 2. Displays title, date, and excerpt for each 3. Handles loading and error states 4. Styles the output with basic CSS Test it in your browser. ### Exercise 8.3: Filter and Search (Level 3) Extend your post list to include: 1. A search input that filters posts by search term 2. A category dropdown that filters by category 3. Pagination (Next/Previous buttons) This combines API parameters with JavaScript event handling. ### Exercise 8.4: Architecture Recommendation (Level 4) A regional newspaper wants to modernise their digital presence. They have: - A 15-year-old WordPress site with 10,000+ articles - A mobile app in development - Plans for a digital subscriber paywall - A team of journalists comfortable with WordPress - One full-stack developer Write a 400-word recommendation addressing: - Should they go headless, traditional, or hybrid? - What are the risks of each approach? - What would you implement first? - How would you handle the transition? ### Exercise 8.5: Architecture Design (Level 5) Design a headless architecture for a restaurant group with: - 5 restaurant locations (different brands) - Shared menu items across some locations - Location-specific events and specials - A central marketing team - Mobile app plans for ordering Create a diagram showing: - What WordPress manages - What the API provides - What the frontend(s) display - How content flows from creation to display Write a 500-word explanation of your design decisions. ## Chapter Summary - Headless architecture separates content management from presentation - The WordPress REST API exposes content as JSON data - Frontends fetch and display content independently - `_embed` includes related data like images and authors - Headless adds complexity but enables multi-channel delivery and modern frontends - Architecture choice depends on requirements, resources, and trade-offs ## Reflection Before moving to the Business Website Project, ensure you can: - [ ] Explain headless architecture without jargon - [ ] Fetch WordPress content using the REST API - [ ] Use API parameters to filter and paginate results - [ ] Access embedded data like featured images - [ ] Articulate when headless makes sense and when it doesn't - [ ] Describe the trade-offs of headless vs. traditional WordPress ## Your Learning Journal Record your responses to these prompts: 1. Architecture Thinking: When you visit websites, can you guess which might be using headless architecture? What clues suggest headless vs. traditional? 2. API Exploration: What surprised you about the WordPress REST API? What data was available that you didn't expect? 3. AI Conversation Reflection: What question about headless architecture did your AI partner help clarify? 4. Trade-off Assessment: Think of a website you might build. Would headless be appropriate? Why or why not? ## Next Steps You've completed Part II: Content Management for Business. You understand: - Why CMS matters and when to use one - WordPress as a platform with an ecosystem - How to extend WordPress professionally - Headless architecture and the REST API In , you'll build a complete WordPress business site, applying everything from this part. This project demonstrates your ability to make and implement technology decisions for real business needs. Then, in Part III, we'll build on the API knowledge from this chapter to create React frontends—bringing modern frontend development into your skillset. ============================================================ SOURCE: projects/project-business-site.qmd ============================================================ # Project: Business Website with WordPress ## Project Overview Part II taught you to think about content management strategically: when to use a CMS, how to evaluate platforms and plugins, and how WordPress architecture works. Now you'll apply that knowledge to build a complete business website. This project simulates a real client engagement. You'll analyse requirements, make technology decisions, implement a solution, and document your choices professionally. The deliverables mirror what you'd provide to an actual client. ## Learning Outcomes Addressed - ULO 2: Demonstrate project management and professional skills - ULO 3: Analyse stakeholder requirements to inform design decisions - ULO 4: Select and integrate appropriate technologies ## Business Scenario Choose one of these scenarios or propose your own: ### Option A: Sunrise Café A local café expanding to two locations. They need: - Menu with categories (drinks, food, specials) - Location pages for each café - Blog for news and events - Contact forms for catering inquiries - Instagram feed integration ### Option B: Hartley & Associates Accountants A small accounting firm establishing online presence. They need: - Service pages (tax, bookkeeping, advisory) - Team member profiles - Blog for tax tips and updates - Client testimonials - Secure contact form for inquiries ### Option C: Community Garden Network A non-profit connecting community gardens. They need: - Garden listings with locations and details - Events calendar - Volunteer signup forms - Resource library (downloadable guides) - Newsletter signup ### Option D: Your Own Scenario Propose a real or fictional business. Must include: - At least three distinct content types - Clear business goals for the website - Identifiable stakeholders - Reasonable scope for this project ## Requirements ### Phase 1: Business Analysis Before touching WordPress, complete: Business Case Document (500-750 words): 1. Business Overview: What does this business do? What's their market position? 2. Website Goals: What should the website achieve? (leads, information, sales, community) 3. Target Audience: Who visits this site? What do they need? 4. Success Metrics: How will we know the website is working? Stakeholder Analysis: | Stakeholder | Needs | Concerns | Priority | |-------------|-------|----------|----------| | (e.g., Owner) | ... | ... | High/Med/Low | Content Strategy: - What content types are needed? - Who creates and maintains each type? - How often does each type update? - What's the approval workflow? Site Map: Create a visual or text-based site map showing: - All pages and their hierarchy - Content types and relationships - Navigation structure ### Phase 2: Technology Decisions Document your decisions with justification: Theme Selection: - Evaluate at least three themes - Document criteria and scores - Justify your final selection - Note any limitations you'll work around Plugin Selection: For each functional requirement, document: - The need it addresses - Options you evaluated - Your selection and why - Any concerns or trade-offs Minimum plugins to evaluate: - Contact forms (e.g., WPForms, Contact Form 7, Gravity Forms) - SEO (e.g., Yoast, RankMath) - Security (e.g., Wordfence, Sucuri) - Backup (e.g., UpdraftPlus) - Any scenario-specific needs ### Phase 3: Implementation Build the site in LocalWP: Core Setup: - [ ] WordPress installed and configured - [ ] Permalinks set to "Post name" - [ ] Site title and tagline configured - [ ] Timezone correct - [ ] Admin user secured (strong password) Theme Implementation: - [ ] Theme installed and activated - [ ] Customiser settings configured (colours, fonts, logo) - [ ] Menus created and assigned - [ ] Homepage configured (static page or blog) - [ ] Child theme created for customisations Content: - [ ] All pages from site map created - [ ] All content types populated with realistic content - [ ] Images appropriately sized and with alt text - [ ] No placeholder/lorem ipsum text Plugins: - [ ] Essential plugins installed and configured - [ ] Contact forms working and tested - [ ] SEO plugin configured (titles, descriptions) - [ ] Security plugin configured - [ ] Backup plugin configured Customisation (Child Theme): - [ ] Child theme created and activated - [ ] At least one CSS customisation implemented - [ ] Customisation survives theme updates ### Phase 4: Testing and Documentation Testing Checklist: - [ ] All pages load without errors - [ ] Navigation works correctly - [ ] Forms submit successfully - [ ] Mobile responsive (test at multiple sizes) - [ ] No JavaScript errors in console - [ ] Images load properly - [ ] Links not broken Technical Documentation: Create a handover document that includes: 1. Login credentials (for a hypothetical client) 2. Theme information (name, version, any modifications) 3. Plugin inventory (name, purpose, configuration notes) 4. Content management guide (how to add/edit content types) 5. Maintenance recommendations (backups, updates, security) ## AI Collaboration Guidelines ### How to Use AI Effectively Use AI as a consultant you're learning from: ### Documentation Requirements Keep an AI collaboration log documenting: 1. Technology decisions: How did AI help evaluate options? 2. Implementation challenges: What problems did you solve with AI help? 3. Modifications: How did you adapt AI suggestions? 4. Learning moments: What did you understand better after AI conversation? ### Client Recommendation Write a summary (300-400 words) as if presenting to the client: - What did you build and why? - What are the key features? - How do they manage content? - What ongoing maintenance is needed? - What future enhancements might they consider? ## Evaluation Criteria ### Business Analysis (25%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Business case | Clear, comprehensive, demonstrates business understanding | Good overview with minor gaps | Basic understanding shown | Incomplete or superficial | | Stakeholder analysis | All stakeholders identified with clear needs | Most stakeholders covered | Some stakeholders identified | Missing or unclear | | Content strategy | Thorough, realistic, actionable | Good strategy with minor gaps | Basic strategy present | Missing or impractical | | Site map | Complete, logical hierarchy | Good structure, minor issues | Basic structure present | Incomplete or illogical | ### Technology Decisions (25%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Theme evaluation | Systematic, documented, justified | Good evaluation with rationale | Basic comparison made | No clear evaluation | | Plugin selection | Evaluated options, documented trade-offs | Good selection with reasons | Functional choices made | Random or unjustified | | Decision documentation | Clear professional documentation | Good documentation | Basic documentation | Missing or poor | ### Implementation (30%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | WordPress setup | Correct configuration, secure | Mostly correct | Functional but issues | Significant problems | | Theme/customisation | Well-configured, child theme works | Good customisation | Basic customisation | No customisation | | Content quality | Professional, realistic, complete | Good content | Basic content | Placeholder content | | Plugin configuration | All plugins properly configured | Most configured correctly | Basic configuration | Unconfigured or broken | | Mobile responsiveness | Excellent on all devices | Good responsive behaviour | Works but issues | Broken on mobile | ### Documentation (20%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Technical docs | Complete handover-ready documentation | Good documentation | Basic documentation | Incomplete | | Client recommendation | Professional, clear, actionable | Good summary | Basic summary | Missing or poor | | AI collaboration log | Detailed, shows critical thinking | Good documentation | Basic log | Missing or superficial | ## Submission Checklist Business Analysis: - [ ] Business case document (500-750 words) - [ ] Stakeholder analysis table - [ ] Content strategy document - [ ] Site map (visual or text) Technical Deliverables: - [ ] WordPress export file (.xml) - [ ] Child theme files (zipped) - [ ] Screenshot of completed site (homepage and two other pages) - [ ] Plugin list with configuration notes Documentation: - [ ] Technical handover document - [ ] Client recommendation summary (300-400 words) - [ ] AI collaboration log ## What to Submit 1. Business analysis package (PDF): Business case, stakeholder analysis, content strategy, site map 2. WordPress export (.xml file): Content export from Tools → Export 3. Child theme (.zip file): Your child theme folder 4. Technical documentation (PDF): Handover document 5. Recommendations and reflection (PDF): Client recommendation + AI collaboration log ## Getting Started Begin with these conversations with your AI partner: ## Common Pitfalls to Avoid 1. Skipping business analysis: Jumping to WordPress without understanding requirements leads to rework 2. Over-complicating: Installing 20 plugins when 5 would suffice 3. Using placeholder content: "Lorem ipsum" signals incomplete work 4. Ignoring mobile: Always test responsive behaviour 5. No documentation: A site without documentation isn't ready for handover 6. Copying AI output blindly: AI helps you understand—you make the decisions 7. Forgetting security: Security and backup plugins are non-negotiable ## Professional Context This project mirrors real WordPress consulting work: 1. Discovery: Understanding business needs before proposing solutions 2. Recommendation: Evaluating options and justifying choices 3. Implementation: Building the solution professionally 4. Handover: Documenting for ongoing maintenance These skills are directly applicable to freelance work, agency positions, or managing WordPress sites in any organisation. ## After Submission Your WordPress project demonstrates: - Business analysis skills - Technology evaluation and decision-making - Practical WordPress implementation - Professional documentation Consider these as portfolio pieces—they show employers you can think beyond just code. ============================================================ SOURCE: chapters/chapter-component-thinking.qmd ============================================================ # Component Thinking: React ## The Concept First In , you learned to fetch content from WordPress via API. But vanilla JavaScript DOM manipulation becomes unwieldy as applications grow. Every change requires finding elements, updating them, keeping track of what's displayed. React solves this by introducing a different mental model: component thinking. Instead of thinking "I need to update this paragraph when data changes," you think "This component displays data. When data changes, React handles the update." Components are self-contained pieces of UI. Each component: - Has its own logic - Manages its own state (data that changes) - Renders its own output - Can be reused anywhere This isn't just a technical convenience—it's a fundamentally different way of building interfaces. Once you think in components, you'll see every UI as a composition of reusable pieces. ## Understanding Through LEGO Consider how LEGO works: - Each brick is self-contained with a consistent interface (the studs) - Complex structures emerge from combining simple pieces - The same brick can be used in many different creations - You can replace one brick without rebuilding everything - Instructions show composition, not monolithic assembly React components work identically: - Each component is self-contained with consistent interfaces (props) - Complex UIs emerge from combining simple components - The same component can be reused throughout your application - You can update one component without touching others - Your code shows composition: components containing components A webpage isn't a monolithic HTML document—it's a tree of components, each responsible for its own piece of the interface. ## The Decomposition Instinct When you see any interface, practice breaking it into components. A navigation bar? That's a `Nav` component containing `NavLink` components. A product card? That's a `ProductCard` containing `Image`, `Title`, `Price`, and `Button` components. This instinct transfers to any component framework. ## Discovering Components with Your AI Partner ### Exploration 1: UI Decomposition Let's practice component thinking before writing code: Your diagram might look like: ### Exploration 2: State vs Props React has two ways data lives in components: state (data the component owns and can change) and props (data passed from a parent). A common analogy: - Props are like instructions parents give to children: "Here's your allowance amount, here's your bedtime." The child receives them but doesn't change them. - State is like the child's own possessions: "I have $5 saved, I'm currently awake." The child controls these and they can change. ### Exploration 3: Data Flow Data in React flows one direction: parent to child (downward). One-way data flow means: - You always know where data came from - Debugging is simpler (trace upward to find the source) - Components are predictable - Changes don't cause cascading side effects ## From Concept to Code Let's build your React understanding progressively. ### Setting Up React The simplest way to start is with Vite, a modern build tool: This creates a React project and starts a development server. Open `http://localhost:5173` to see it running. ## Prerequisites You need Node.js installed. Download from nodejs.org if you haven't already. ### JSX: HTML in JavaScript React uses JSX—a syntax that lets you write HTML-like code in JavaScript: This looks like HTML but it's actually JavaScript. JSX gets transformed into function calls that create elements. Key JSX differences from HTML: | HTML | JSX | |------|-----| | `class="..."` | `className="..."` | | `for="..."` | `htmlFor="..."` | | `onclick="..."` | `onClick={...}` | | Self-closing optional | Self-closing required: `` | JavaScript expressions go inside curly braces: ### Your First Component Components are functions that return JSX: Use components like HTML elements: Three product cards appear—but they're all identical. To make them different, we need props. ### Props: Configuring Components Props pass data from parent to child: Now each card displays different data. The component is reusable—same structure, different content. Props can be any JavaScript value: ### State: Data That Changes Props come from outside; state lives inside the component and can change. `useState` returns two things: 1. The current value (`count`) 2. A function to update it (`setCount`) When you call `setCount`, React re-renders the component with the new value. You don't manually update the DOM—React handles it. ### More State Examples Toggle: Form input: ### Lists and Keys To render a list, use JavaScript's `map`: The `key` prop helps React track which items changed. Use a unique identifier (like `id`), not the array index. ### useEffect: Side Effects and Data Fetching Components sometimes need to do things besides rendering: fetch data, set up subscriptions, update the document title. These are side effects. The `useEffect` hook: - Runs after the component renders - The empty `[]` dependency array means "run only once" - Perfect for data fetching when component loads ### Connecting to WordPress Remember the WordPress REST API from ? Let's fetch WordPress posts: ## dangerouslySetInnerHTML WordPress returns HTML in `rendered` fields. React requires `dangerouslySetInnerHTML` to insert raw HTML. Only use this with trusted content (like your own WordPress site)—never with user input. ### Component Composition Build complex UIs by composing simple components: Each component is small, focused, and understandable. The composition creates the full application. ## Building Your Mental Model ### The Component Tree Your application forms a tree of components: Data flows down this tree. State lives in the component that "owns" it—often a parent that passes it to children. ### When State Should "Lift Up" If two sibling components need the same data, the state should live in their common parent: This is called "lifting state up"—moving state to the lowest common ancestor. ### The Rendering Cycle You don't touch the DOM. You declare what should appear based on state. React efficiently updates only what changed. ## Business Applications ### Reusability Build a `Button` component once with variants (primary, secondary, danger). Use it everywhere. Update the design in one place, and every button updates. ### Maintainability When a feature needs updating, you know exactly which component to modify. Components are isolated—changes don't ripple unexpectedly. ### Team Collaboration Different developers can work on different components simultaneously. The interface (props) defines how components connect—teams don't need to understand each other's implementation details. ### Testing Components can be tested in isolation. Does `ProductCard` render correctly with these props? Does `Counter` increment when clicked? Unit tests are straightforward. ### Design Systems React components naturally form design systems. Your `Button`, `Card`, `Input`, and `Modal` components become a library that enforces consistency across the application. ## ULO Connection This develops ULO 1 (effective web applications) and ULO 4 (technology selection). React's component model is influential across the industry—understanding it prepares you for Vue, Angular, and other frameworks that share similar concepts. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 9.1: First Component (Level 1) Create a React project with Vite and build a `Greeting` component that: 1. Accepts a `name` prop 2. Displays "Hello, {name}!" 3. Is used three times in `App` with different names ### Exercise 9.2: Stateful Component (Level 2) Build a `LikeButton` component that: 1. Displays a heart icon (can be emoji ❤️) 2. Shows a like count starting at 0 3. Increments the count when clicked 4. Changes colour when count > 0 ### Exercise 9.3: List Rendering (Level 3) Build a `TaskList` component that: 1. Accepts an array of tasks as props 2. Renders each task as a `TaskItem` component 3. Each `TaskItem` shows the task text and a "Complete" button 4. Clicking "Complete" removes the task (hint: lift state up) ### Exercise 9.4: Data Fetching (Level 4) Build a `UserList` component that: 1. Fetches users from `https://jsonplaceholder.typicode.com/users` 2. Displays loading state while fetching 3. Handles errors gracefully 4. Renders each user as a `UserCard` with name and email 5. Allows clicking a user to show more details ### Exercise 9.5: WordPress Integration (Level 5) Build a mini blog frontend that: 1. Fetches posts from your local WordPress site (or JSONPlaceholder) 2. Displays posts in a `PostList` component 3. Allows clicking a post to see full content in a `PostDetail` component 4. Includes a search box that filters posts by title 5. Handles loading and error states throughout Document your component structure and explain your state management decisions. ## Chapter Summary - Components are reusable, self-contained UI pieces - Props pass data from parent to child (read-only) - State is data the component owns and can change - `useState` creates state; `useEffect` handles side effects - Data flows one direction: parent to child - Component thinking is transferable to other frameworks ## Reflection Before moving to Chapter 10, ensure you can: - [ ] Break down a UI into a component hierarchy - [ ] Create functional components with JSX - [ ] Pass data with props and explain why props are read-only - [ ] Use `useState` to manage component state - [ ] Fetch data with `useEffect` - [ ] Render lists with `map` and explain why keys matter - [ ] Explain how React's one-way data flow works ## Your Learning Journal Record your responses to these prompts: 1. Decomposition Practice: Pick any website you use. Sketch how you'd break it into React components. What would be reusable? 2. State Analysis: Think about a form you've filled out online. What state would it need? Where would that state live? 3. AI Conversation Reflection: What React concept was hardest to grasp? What question to your AI partner helped clarify it? 4. Mental Model Shift: How is thinking in components different from the vanilla JavaScript approach in earlier chapters? What's easier? What's harder? ## Next Steps You can now build component-based interfaces and fetch data from APIs. But styling components from scratch takes time. In , we'll explore CSS frameworks—Bootstrap and Tailwind—that provide pre-built styles and utilities. Combined with React, these tools enable rapid professional development without designing every button and layout from scratch. ============================================================ SOURCE: chapters/chapter-rapid-development.qmd ============================================================ # Rapid Development: CSS Frameworks ## The Concept First In , you learned CSS from scratch—selectors, box model, flexbox, media queries. That foundation matters. But building every project from zero is slow, and consistency across large applications is hard. CSS frameworks solve this by providing pre-built styles, components, and design decisions. Instead of designing every button, input, and card yourself, you adopt tested patterns that work together. This isn't laziness—it's leverage. Professional developers use frameworks to move faster while maintaining quality. The skill is knowing when to use them, which to choose, and how to customise them for specific needs. ## Understanding Through Design Systems Large organisations don't let every designer create their own button styles. They create design systems—documented collections of components, colours, typography, and patterns that ensure consistency. Google has Material Design. Apple has Human Interface Guidelines. Salesforce has Lightning Design System. These define how interfaces should look and behave across products. CSS frameworks are design systems you can adopt immediately: - Bootstrap: Component-focused system with pre-built UI elements - Tailwind CSS: Utility-focused system with building blocks for custom designs - Foundation, Bulma, Chakra UI: Other popular options Each makes different trade-offs. Understanding those trade-offs is how you choose wisely. ## Constraints Enable Speed Paradoxically, constraints often speed up creative work. When you don't have to decide every colour, spacing, and font size, you can focus on structure and user experience. Frameworks provide productive constraints. ## Discovering Frameworks with Your AI Partner ### Exploration 1: Framework Philosophies Bootstrap and Tailwind represent fundamentally different approaches: This should reveal: Bootstrap approach: - "Here's a button: `.btn .btn-primary`" - Faster to start - Consistent out of the box - Can look generic without customisation Tailwind approach: - "Build your button: `bg-blue-500 text-white px-4 py-2 rounded`" - More markup - Maximum flexibility - Requires more design decisions ### Exploration 2: Constraints as Features How do limitations help? Constraints reduce decision fatigue. When a framework says "primary buttons are this colour, secondary buttons are that colour," you're not spending mental energy on decisions that don't differentiate your product. ### Exploration 3: The "Generic" Problem This reveals that frameworks are starting points, not endpoints. Customisation—colours, typography, spacing—transforms a generic framework site into something unique. ## From Concept to Code Let's explore both Bootstrap and Tailwind practically. ### Bootstrap: Component-Based Framework Bootstrap provides pre-styled components you assemble. Setup in HTML: Buttons: Cards: Grid System: The grid is 12 columns wide. `col-md-4` means "4 columns wide on medium screens and up." On smaller screens, columns stack vertically. Responsive utilities: ### Tailwind CSS: Utility-First Framework Tailwind provides low-level utility classes you combine. Setup (simplest via CDN for learning): ## Production Setup For production, install Tailwind via npm and build a custom CSS file. The CDN is for learning and prototyping only. Buttons (you design them): Understanding the classes: | Class | Meaning | |-------|---------| | `bg-blue-500` | Background colour (blue, shade 500) | | `text-white` | Text colour white | | `px-4` | Padding horizontal (left/right), size 4 | | `py-2` | Padding vertical (top/bottom), size 2 | | `rounded` | Border radius | | `hover:bg-blue-600` | On hover, darker blue | Cards: Flexbox layout: Responsive design: Tailwind's breakpoint prefixes: `sm:`, `md:`, `lg:`, `xl:`, `2xl:`. ### Using Frameworks with React Both frameworks work well with React. Bootstrap with React: For components with JavaScript (modals, dropdowns), consider `react-bootstrap`: Tailwind with React: Configure `tailwind.config.js`: Add to your CSS file: Use in components: ### Customisation Bootstrap customisation (via Sass): Tailwind customisation (via config): Then use: `bg-brand`, `text-brand-dark`, etc. ## Building Your Mental Model ### The Abstraction Spectrum Move right for more control, left for more speed. Project needs determine the right position. ### When to Choose What | Situation | Consider | |-----------|----------| | Rapid prototyping | Bootstrap or component library | | Admin dashboards | Bootstrap (consistent patterns) | | Marketing sites | Tailwind (unique designs) | | Highly custom UI | Tailwind or custom CSS | | Team with designers | Tailwind (matches design tokens) | | Team without designers | Bootstrap (built-in design decisions) | | Learning CSS | Start custom, add frameworks later | ### The Class Explosion Concern Tailwind markup can look verbose: Solutions: 1. Extract components (in React, this is natural) 2. Use @apply in CSS (creates reusable classes) 3. Accept the trade-off (markup complexity vs CSS complexity) ## Business Applications ### Development Speed Frameworks dramatically reduce time-to-market: - Pre-built responsive grids - Tested browser compatibility - Accessible components (often) - Documentation and examples What takes days in custom CSS takes hours with frameworks. ### Consistency at Scale Large applications need consistent interfaces. Frameworks enforce consistency: - All buttons look like buttons - All cards have the same shadow - Spacing follows a system - Typography is unified This consistency improves user experience and reduces maintenance. ### Team Efficiency New team members can contribute faster when using standard frameworks: - Well-documented - Familiar patterns - Searchable solutions online - Reduced onboarding time ### Mobile-First by Default Modern frameworks are mobile-responsive out of the box. Bootstrap's grid and Tailwind's responsive prefixes handle responsive design that would take significant custom CSS. ## ULO Connection This develops ULO 4 (selecting and integrating technologies) and ULO 1 (effective web applications). Framework selection is a business decision—speed vs. customisation, team skills, project timeline. Professional judgment means choosing appropriately, not defaulting to what you know. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 10.1: Bootstrap Basics (Level 1) Create an HTML page using Bootstrap that includes: 1. A navigation bar with a brand name and three links 2. A hero section with a heading, paragraph, and button 3. A three-column grid of cards 4. A footer with centred text Use only Bootstrap classes—no custom CSS. ### Exercise 10.2: Tailwind Basics (Level 2) Recreate the same layout from Exercise 10.1 using Tailwind: 1. Navigation bar 2. Hero section 3. Three-column responsive grid 4. Footer Compare the experience. Which felt faster? Which gave more control? ### Exercise 10.3: React + Framework (Level 3) In a React project: 1. Choose either Bootstrap or Tailwind 2. Create a `ProductCard` component 3. Create a `ProductGrid` component that displays multiple cards 4. Make it responsive (single column on mobile, grid on desktop) 5. Add a "Featured" variant of the card with different styling ### Exercise 10.4: Customisation (Level 4) Take your Exercise 10.3 project and customise the framework: 1. Change the primary colour to a custom brand colour 2. Adjust the border radius across components 3. Modify the default font family 4. Document the customisation process Write 200 words explaining how customisation changes the "generic" feel. ### Exercise 10.5: Framework Recommendation (Level 5) A startup is building a SaaS product dashboard. They have: - Two developers (full-stack, not design-focused) - Tight three-month deadline - Need for admin panels, data tables, forms, charts - Plans to hire a designer in six months Write a 500-word recommendation: 1. Which framework would you recommend? 2. What's the trade-off they're accepting? 3. How should they approach customisation? 4. What happens when the designer arrives? 5. What alternatives did you consider? ## Chapter Summary - CSS frameworks provide pre-built styles and design systems - Bootstrap offers component-based development with pre-styled elements - Tailwind offers utility-based development with maximum flexibility - Both work well with React - Framework choice depends on project needs, team skills, and timeline - Customisation transforms generic frameworks into branded experiences ## Reflection Before moving to Chapter 11, ensure you can: - [ ] Explain the difference between component and utility frameworks - [ ] Use Bootstrap to create responsive layouts and components - [ ] Use Tailwind to style elements with utility classes - [ ] Integrate either framework with React - [ ] Customise framework colours, fonts, and spacing - [ ] Articulate when to choose each framework ## Your Learning Journal Record your responses to these prompts: 1. Preference Exploration: After trying both Bootstrap and Tailwind, which felt more natural to you? Why might someone prefer the other? 2. Trade-off Analysis: Think of a project you might build. Which framework would you choose and what trade-offs would you accept? 3. AI Conversation Reflection: What framework concept was hardest to grasp? What question to your AI partner helped clarify it? 4. Professional Judgment: A client asks "Why don't we just use custom CSS?" How would you respond? ## Next Steps You now have tools for rapid, consistent UI development. But professional work requires more than just building features—it requires practices that ensure quality, collaboration, and maintainability. In , we'll cover version control with Git, testing basics, and code quality practices. These professional practices separate hobby projects from production-ready work and are expected in any development role. ============================================================ SOURCE: chapters/chapter-professional-practices.qmd ============================================================ # Professional Practices ## The Concept First In , you learned to build interfaces quickly with CSS frameworks. But professional development isn't just about building features—it's about building sustainable, reliable, collaborative systems. Consider the difference: - Hobbyist: Gets the feature working, moves on - Professional: Gets the feature working, ensures it stays working, makes it easy for others to understand and modify Professional practices aren't bureaucracy—they're risk management. Every project eventually faces: - "It was working yesterday. What changed?" - "I can't remember why I wrote this code." - "Someone else needs to fix this while I'm on holiday." - "The client changed their mind. Can we undo this?" Professional practices answer these questions before they become crises. They're the difference between code that works today and code that keeps working tomorrow. ## Understanding Through Craftsmanship Consider two furniture makers: The first measures wood, cuts it, assembles pieces. If something doesn't fit, they shave a bit here, add a shim there. The table works, but any later modification requires figuring out all the adjustments again. The second measures twice, documents the cuts, keeps offcuts labelled, photographs each stage. If something doesn't fit, they can trace exactly where the deviation started. Years later, they can build a matching chair. Both produce functional furniture. But the second can: - Train apprentices using their documentation - Reproduce work reliably - Fix problems systematically - Collaborate with other craftspeople Software development is the same. Version control is measuring twice. Testing is quality checks before delivery. Documentation is the labelled workshop. ## Professional Practice Serves Future You In six months, you won't remember why you made certain decisions. Professional practices create a trail for "future you" to follow. That's not extra work—it's insurance. ## Discovering Professional Practices with Your AI Partner ### Exploration 1: Why Version Control Matters This should reveal: - Overwriting each other's work - No way to revert mistakes - "Which version is the real one?" - Fear of making changes - No history of what changed or why ### Exploration 2: The Testing Mindset Testing isn't about distrust—it's about confidence. Key insights: - Manual testing doesn't scale - Humans miss things, especially when tired - Automated tests run every time, consistently - Tests document expected behaviour - Regression testing catches "breaking old stuff while adding new" ### Exploration 3: Code as Communication Code is read far more than it's written. Every piece of code is communication with: - Future you - Teammates - Future maintainers This reveals: - Meaningful variable names - Logical structure - Appropriate comments (why, not what) - Consistent formatting - Small, focused functions ### Exploration 4: Documentation Purpose Different documentation serves different audiences: - Code comments: Future developers modifying the code - README: Anyone encountering the project for the first time - Technical docs: Users of your code (API consumers, library users) - User docs: Non-technical end users ## From Concept to Code ### Git: Version Control Fundamentals Git tracks changes to files over time. The mental model: Initial setup: Starting a project: Basic workflow: Understanding the commands: | Command | What it does | |---------|-------------| | `git status` | Shows changed, staged, and untracked files | | `git add` | Moves changes to staging area | | `git commit` | Creates permanent snapshot with message | | `git log` | Shows commit history | | `git diff` | Shows what changed (unstaged changes) | ## Commit Messages Matter Good: "Fix login timeout on slow connections" Bad: "Fixed bug" or "Updates" The message should explain why you made the change, not what files you touched. Future you needs to understand the intent. Working with branches: Branches let you work on features without affecting the main code: Working with GitHub: ### Testing: Starting Simple Testing verifies your code does what you expect. Start simple: Manual test file (for learning): Using a testing framework (Vitest with React/Vite): Run tests: What to test: Focus on behaviour, not implementation: ### Code Quality Practices Meaningful names: Small, focused functions: Comments that explain why: Consistent formatting: Use a formatter like Prettier: Use a linter like ESLint: These tools enforce consistency automatically—no arguments about tabs vs spaces. ### Documentation Essentials README.md (project overview): bash npm install bash npm run dev Code documentation (JSDoc): ## Building Your Mental Model ### The Professional Practice Pyramid Each layer builds on the one below. You can't effectively review code that isn't in version control. You can't confidently test code that's poorly structured. Start from the foundation. ### The Cost of Skipping Practices Professional practices have upfront cost but prevent exponential debugging later. ### When Each Practice Matters Most | Practice | Solo Project | Team Project | Long-term Maintenance | |----------|-------------|--------------|----------------------| | Version Control | Essential | Critical | Critical | | Testing | Valuable | Essential | Critical | | Code Quality | Valuable | Essential | Critical | | Documentation | Helpful | Essential | Critical | | Code Review | N/A | Essential | Essential | Even solo projects benefit from version control and testing. The "team" includes future you. ## Business Applications ### Risk Reduction Version control isn't just convenience—it's business continuity: - Roll back problematic deployments - Trace when bugs were introduced - Prove what was deployed when - Recover from disasters (laptop theft, hardware failure) For clients: "Your entire codebase is safely stored with complete history. If anything goes wrong, we can restore any previous version." ### Quality Assurance Testing provides business confidence: - Catch bugs before customers do - Verify features work after changes - Reduce manual testing costs - Enable faster, safer deployments For clients: "Before any release, automated tests verify the critical functionality. This catches problems before your customers see them." ### Collaboration and Onboarding Good practices enable team growth: - New developers understand the codebase faster - Documentation reduces "tribal knowledge" dependency - Consistent style means anyone can work on any file - Code review spreads knowledge across the team For clients: "If a developer leaves, their work is documented and reviewable. You're not dependent on any single person." ### Long-term Maintainability Code lives longer than developers expect: - "Quick fix" becomes permanent - "Temporary project" runs for years - "Solo project" gets a team Professional practices from the start prevent painful migrations later. ## ULO Connection This develops ULO 2 (professional project management) and ULO 1 (iteratively improving solutions). Professional practices aren't separate from development—they're how professionals develop. These skills are expected in any development role. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 11.1: Git Fundamentals (Level 1) Create a new project with Git: 1. Create a folder with an `index.html` file 2. Initialise a Git repository 3. Stage and commit the file with a meaningful message 4. Make changes to the file 5. View the diff, then commit the changes 6. View the commit history Document the commands you used and what each did. ### Exercise 11.2: Branching Workflow (Level 2) Extend Exercise 11.1: 1. Create a branch called `feature/styling` 2. Add a `styles.css` file and link it in HTML 3. Commit the changes on the branch 4. Switch back to main 5. Verify the CSS file isn't there 6. Merge the feature branch into main 7. Verify the CSS file now exists on main Document when you'd use this workflow in a real project. ### Exercise 11.3: First Tests (Level 3) Create a JavaScript module with tests: 1. Create a `utils.js` file with these functions: - `capitalise(string)` - capitalises the first letter - `truncate(string, length)` - shortens string to length with "..." - `slugify(string)` - converts to URL-safe slug 2. Install Vitest 3. Write tests for each function covering: - Normal cases - Edge cases (empty string, already capitalised) - Error cases (invalid input) 4. Run tests and ensure they pass ### Exercise 11.4: Testing a Component (Level 4) Create a React component with tests: 1. Build a `SearchFilter` component that: - Shows an input field - Displays a list of items - Filters items as user types 2. Write tests that verify: - Component renders with provided items - Typing filters the displayed items - Clearing input shows all items - Empty state displays appropriately Focus on testing behaviour from the user's perspective. ### Exercise 11.5: Professional Project Setup (Level 5) Set up a complete project with professional practices: 1. Create a React project with Vite 2. Initialise Git repository 3. Create meaningful `.gitignore` 4. Set up ESLint and Prettier 5. Configure Vitest for testing 6. Write a comprehensive README 7. Create an initial commit with good message 8. Push to GitHub Write 300 words explaining each decision you made and why these practices matter. ## Chapter Summary - Version control (Git) tracks changes and enables collaboration - Testing provides confidence that code works correctly - Code quality practices make code readable and maintainable - Documentation serves future developers (including yourself) - Professional practices have upfront cost but prevent exponential debugging later - These practices are expected in professional development roles ## Reflection Before moving to the React Integration Project, ensure you can: - [ ] Initialise a Git repository and make commits - [ ] Create branches and merge them - [ ] Write basic automated tests - [ ] Explain why testing matters beyond "it works" - [ ] Identify ways to make code more readable - [ ] Create useful README documentation - [ ] Articulate the business value of professional practices ## Your Learning Journal Record your responses to these prompts: 1. Practice Value: Which professional practice do you think will have the most impact on your work? Why? 2. Real Experience: Think of a time you lost work or couldn't remember why you made a decision. How would version control or documentation have helped? 3. AI Conversation Reflection: What professional practice concept was hardest to grasp? What question to your AI partner helped clarify it? 4. Team Perspective: If you were hiring a junior developer, which of these practices would you most want them to understand? ## Next Steps You now have both the technical skills (HTML, CSS, JavaScript, React, CSS frameworks) and professional practices (version control, testing, documentation) to build production-quality applications. In the React Integration Project (), you'll bring everything together: build a React frontend that consumes WordPress content via API, styled with a CSS framework, using professional version control and documentation practices. This capstone project demonstrates your complete frontend development capabilities. ============================================================ SOURCE: projects/project-react-integration.qmd ============================================================ # Project: React Integration ## Project Overview Part III taught you component thinking, CSS frameworks, and professional practices. Now you'll bring it together: build a React frontend that consumes content from WordPress via the REST API, demonstrating headless architecture in action. This project bridges backend content management with modern frontend development. You'll make architectural decisions, implement a complete application, and document your approach—skills that directly translate to professional frontend development roles. ## Learning Outcomes Addressed - ULO 1: Design and implement effective web applications - ULO 4: Select and integrate appropriate technologies - ULO 5: Evaluate emerging technologies and approaches ## Technical Context In , you learned that headless WordPress separates content management (WordPress) from content presentation (your frontend). This project implements that architecture: Your React application will fetch and display content that's managed in WordPress—the same content model used by major publishers, e-commerce sites, and enterprise applications. ## Project Scenarios Choose one scenario that builds on your WordPress site from the Business Site Project, or create new content: ### Option A: Blog Frontend Transform your WordPress blog into a modern React single-page application: - Post listing with categories - Individual post pages - Author information display - Search functionality - Category filtering ### Option B: Portfolio Showcase Display portfolio items or projects from WordPress: - Grid/list view of projects - Project detail pages with images - Category or technology filtering - Contact form integration ### Option C: Business Directory Create a directory interface for business listings: - Searchable listing grid - Individual business pages - Location or category filtering - Featured listings section ### Option D: Custom Application Propose your own application that: - Consumes WordPress REST API content - Has at least two distinct views (list and detail) - Includes meaningful filtering or search - Demonstrates component architecture ## Requirements ### Phase 1: Planning and Setup Before writing code, document your approach: Application Design Document (300-500 words): 1. Scenario Overview: Which scenario did you choose and why? 2. Component Architecture: What components will you need? Draw a component tree. 3. Data Requirements: What WordPress content will you fetch? What endpoints? 4. User Interface: Sketch or describe the main views 5. Technology Choices: Which CSS framework? Why? Component Tree Example: ### Phase 2: React Implementation Build the application with these requirements: Core Setup: - [ ] React project created with Vite - [ ] Git repository initialised - [ ] CSS framework installed and configured - [ ] Project structure organised logically - [ ] README with setup instructions Component Architecture: - [ ] At least 5 distinct components - [ ] Proper use of props for data passing - [ ] State management with useState - [ ] Side effects with useEffect - [ ] Components are reusable where appropriate WordPress Integration: - [ ] Fetch posts from WordPress REST API - [ ] Handle loading states (spinner, skeleton, or message) - [ ] Handle error states gracefully - [ ] Display at least 3 post fields (title, content, excerpt, author, date, etc.) - [ ] Images loaded from WordPress media User Interface: - [ ] List view showing multiple items - [ ] Detail view showing single item - [ ] Navigation between views (useState or React Router) - [ ] Responsive design (works on mobile and desktop) - [ ] Consistent styling with chosen CSS framework Professional Practices: - [ ] Meaningful Git commits throughout development - [ ] Code formatted consistently (Prettier recommended) - [ ] No console errors or warnings in final version - [ ] Comments where logic isn't self-evident ### Phase 3: Enhanced Features Implement at least TWO of the following: Search/Filter: - [ ] Search posts by title or content - [ ] Filter by category or tag - [ ] Clear filters to show all Pagination: - [ ] Load more posts on demand - [ ] Or implement traditional pagination - [ ] Handle edge cases (no more posts, first page) Routing: - [ ] React Router for URL-based navigation - [ ] Direct links to individual posts - [ ] Back navigation works correctly Additional Content: - [ ] Display WordPress pages (not just posts) - [ ] Show author information with avatar - [ ] Display featured images properly ### Phase 4: Documentation and Reflection Technical Documentation: Create a README.md that includes: 1. Project Description: What the application does 2. Setup Instructions: How to run locally 3. WordPress Configuration: Required WordPress setup 4. Architecture Overview: How components fit together 5. API Endpoints Used: Which WordPress endpoints and why Reflection Document (500-700 words): 1. Headless Architecture: What are the advantages and disadvantages of this approach compared to traditional WordPress themes? 2. Component Decisions: Describe two components you created. Why did you structure them that way? What data do they receive and display? 3. State Management: Where does state live in your application? Why did you put it there? 4. Challenges and Solutions: What was the hardest part of this project? How did you solve it? 5. Future Improvements: If you had more time, what would you add or change? ## AI Collaboration Guidelines ### Effective AI Partnership Use AI as a thinking partner, not a code generator: ### AI Collaboration Log Document your AI interactions: | Challenge | Question Asked | AI Response Summary | How I Applied It | |-----------|---------------|---------------------|------------------| | (e.g., Images not loading) | ... | ... | ... | For each significant interaction: 1. What problem were you solving? 2. What did you ask? 3. What did the AI explain? 4. How did you adapt the suggestion to your specific situation? 5. What did you learn that you'll use again? ### Attribution Requirements Be clear about AI involvement: - Code you wrote yourself vs. code adapted from AI suggestions - Concepts you learned through AI conversation - Documentation created with AI assistance This isn't about restricting AI use—it's about demonstrating that you understood what you built. ## Evaluation Criteria ### Planning and Design (15%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Application design | Clear architecture, thoughtful component breakdown | Good planning with minor gaps | Basic planning present | Incomplete or unclear | | Technology justification | Clear reasoning for all choices | Good justification for most | Basic reasoning provided | No justification | | Component tree | Complete, logical hierarchy | Good structure, minor issues | Basic structure shown | Missing or illogical | ### React Implementation (35%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Component architecture | Well-structured, reusable, single responsibility | Good structure with minor issues | Functional but not well organised | Poor structure or monolithic | | Props and state | Correct use, appropriate lifting | Mostly correct usage | Basic usage, some issues | Incorrect or missing | | API integration | Robust fetching, proper error handling | Good integration, minor gaps | Basic fetching works | Broken or incomplete | | useEffect usage | Correct dependencies, no unnecessary calls | Mostly correct | Functional but issues | Incorrect or missing | ### User Interface (25%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Visual design | Professional, consistent, polished | Good design, minor inconsistencies | Functional but basic | Broken or unstyled | | Responsive design | Excellent on all screen sizes | Good responsive behaviour | Works but issues | Broken on mobile | | Loading/error states | Clear, helpful, consistent | Present and functional | Basic handling | Missing or broken | | Navigation | Intuitive, works correctly | Good navigation, minor issues | Functional but awkward | Broken or missing | ### Professional Practices (10%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Git usage | Meaningful commits throughout | Good commit history | Some commits | No commits or single commit | | Code quality | Clean, consistent, readable | Good quality, minor issues | Functional but messy | Poor quality | | README | Complete, clear, helpful | Good documentation | Basic documentation | Missing or incomplete | ### Reflection and AI Collaboration (15%) | Criteria | Excellent (4) | Good (3) | Adequate (2) | Needs Work (1) | |----------|--------------|----------|--------------|----------------| | Headless architecture reflection | Deep understanding demonstrated | Good understanding shown | Basic understanding | Missing or superficial | | Component decisions | Clear reasoning, shows learning | Good explanations | Basic explanations | Missing or unclear | | AI collaboration log | Detailed, shows critical thinking | Good documentation | Basic log present | Missing or superficial | | Learning demonstrated | Clear growth and understanding | Good learning shown | Some learning evident | No learning demonstrated | ## Submission Checklist Code: - [ ] Complete React source code (exclude `node_modules`) - [ ] `package.json` with all dependencies - [ ] `.gitignore` properly configured - [ ] No API keys or secrets in code Documentation: - [ ] README.md with setup instructions - [ ] Application design document - [ ] Reflection document (500-700 words) - [ ] AI collaboration log Demonstration: - [ ] Screenshots of main views (list, detail, mobile) - [ ] Screenshot of loading state - [ ] Screenshot of error state (simulated if necessary) WordPress: - [ ] WordPress export file (if content is needed) - [ ] Or note that app uses public API/test data ## Getting Started Begin with these conversations: ## Common Pitfalls to Avoid 1. Skipping the plan: Jumping into code without designing component architecture leads to refactoring 2. One giant component: Put everything in App.js instead of breaking into focused components 3. Ignoring loading states: App breaks or shows nothing while data loads 4. No error handling: App crashes when API fails instead of showing helpful message 5. Props drilling confusion: Not understanding where state should live 6. Not using keys in lists: Causes warnings and potential bugs 7. Committing node_modules: Makes repository huge and unusable 8. Hardcoded URLs: API endpoints should be configurable or documented ## Technical Tips Fetching WordPress posts with featured images: Project structure suggestion: useState for view navigation: ## Professional Context This project demonstrates skills employers look for: 1. Frontend architecture: Structuring React applications logically 2. API integration: Working with external data sources 3. State management: Handling application data flow 4. User experience: Loading states, error handling, responsive design 5. Professional practices: Version control, documentation, code quality Headless architecture is increasingly common in enterprise development. Understanding how to build frontends that consume APIs—whether WordPress, a custom backend, or third-party services—is valuable regardless of your eventual specialisation. ## After Submission This project, combined with your WordPress Business Site, demonstrates full-stack thinking: - Backend: WordPress content management - API: REST interface design - Frontend: React component architecture - Professional: Version control, documentation, testing Consider extending this portfolio piece by: - Adding more interactive features - Implementing React Router for proper URLs - Adding tests with Vitest - Deploying to a hosting service These extensions show initiative and technical depth to potential employers. ============================================================ SOURCE: chapters/chapter-emerging-technologies.qmd ============================================================ # Evaluating Emerging Technologies ## The Concept First In , you learned practices that make developers effective. But the technology landscape changes constantly. The frameworks popular today may be legacy tomorrow. The "best practices" of five years ago may now be anti-patterns. This creates a challenge: how do you evaluate new technologies without getting swept up in hype? The answer isn't to know every new tool—that's impossible. The answer is developing a systematic evaluation framework that works for any technology. This meta-skill outlasts any specific tool. Consider the difference: - Chasing trends: "Everyone's using X, we should too" - Systematic evaluation: "X solves problem Y with trade-offs Z. Given our context, is it appropriate?" The second approach serves you for your entire career, regardless of which technologies rise and fall. ## Understanding Through Investment Thinking Adopting a technology is an investment decision. Like financial investments, technology investments have: - Upfront costs: Learning time, integration effort, migration pain - Ongoing costs: Maintenance, updates, ecosystem changes - Expected returns: Productivity gains, capability improvements, competitive advantages - Risks: Technology abandonment, breaking changes, hiring difficulties Smart investors don't just ask "Will this stock go up?" They ask "Given my goals, timeline, and risk tolerance, is this the right investment?" Smart technologists don't just ask "Is this technology good?" They ask "Given our problem, team, timeline, and constraints, is this technology appropriate?" ## The Hype Cycle Awareness New technologies typically follow a pattern: initial hype, peak of inflated expectations, trough of disillusionment, and finally a plateau of productivity. Understanding where a technology sits on this curve helps calibrate your evaluation. ## Discovering Evaluation with Your AI Partner ### Exploration 1: Building an Evaluation Framework A good framework might include: Problem Fit: - What specific problem does this solve? - Do we actually have this problem? - How are we solving it currently? - How painful is the current solution? Maturity and Stability: - How long has this technology existed? - Who is using it in production? - How frequently do breaking changes occur? - What's the governance model (company, community, foundation)? Ecosystem and Support: - What's the documentation quality? - How active is the community? - Are there quality learning resources? - Can we hire people who know this? Integration and Migration: - How does this fit with our existing stack? - What's the migration path? - Can we adopt incrementally? - What's the rollback strategy? Total Cost: - What's the learning curve? - What are ongoing maintenance requirements? - Are there licensing costs? - What's the opportunity cost of adoption time? ### Exploration 2: Distinguishing Hype from Value This should reveal patterns: Signs of hype without substance: - Solves problems most projects don't have - Benefits are vague ("makes development better") - Requires rewriting everything to adopt - Community focuses on features, not outcomes Signs of genuine value: - Addresses real, common pain points - Benefits are concrete and measurable - Can be adopted incrementally - Users talk about problems solved, not features ### Exploration 3: Current Technology Landscape Technologies change, but evaluation skills persist. Let's practice: As of this book's writing, relevant technologies include: - TypeScript: Type safety for JavaScript - Server-side rendering (SSR): Performance and SEO - Edge computing: Latency and global distribution - Progressive Web Apps (PWAs): Native-like web experiences - AI-assisted development: Code generation and assistance ### Exploration 4: Learning from History This develops healthy scepticism. Technologies that seemed essential often: - Were replaced by simpler alternatives - Solved problems that platforms eventually solved - Had high adoption costs that weren't justified - Were driven by specific company interests ## From Concept to Code Let's explore practical examples of emerging patterns. ### TypeScript: Adding Types to JavaScript TypeScript adds static typing to JavaScript. The evaluation: Problem it solves: - Runtime errors from type mismatches - Difficulty understanding code at scale - Refactoring without confidence - Poor IDE support for large codebases Trade-offs: - Additional compilation step - Learning curve for type system - More verbose code - Build tooling complexity Example comparison: When TypeScript makes sense: - Teams larger than 2-3 people - Codebases expected to grow significantly - APIs consumed by multiple clients - Long-lived projects When to skip TypeScript: - Quick prototypes - Solo projects with short lifespans - Teams with no TypeScript experience and tight deadlines ### Progressive Web Apps (PWAs) PWAs use web technologies to deliver app-like experiences. Problem they solve: - App store friction for distribution - Need for offline functionality - Push notification capability - Installation on home screen Trade-offs: - More complex than standard websites - iOS support limitations - Not all native features available - User education about "installation" Basic PWA structure: When PWAs make sense: - Content-focused apps needing offline access - Avoiding app store distribution - Cross-platform with single codebase - Re-engagement via notifications When to use native/hybrid instead: - Heavy device feature requirements - Performance-critical applications - App store presence is valuable - Complex offline data sync needs ### Server Components and SSR Modern frameworks offer server-side rendering and server components. Problem they solve: - Slow initial page load (JavaScript bundle download) - Poor SEO for dynamic content - Layout shift after hydration - Server-client data duplication Trade-offs: - Server infrastructure required - More complex mental model - Debugging across client/server boundary - Caching complexity Mental model: ### Evaluating AI-Assisted Development AI coding assistants are a current example of technology requiring evaluation. Problem they solve: - Boilerplate code writing - Remembering syntax and APIs - Exploring unfamiliar codebases - Documentation lookup Trade-offs: - Code quality varies - May perpetuate bad patterns - Over-reliance reduces learning - Security/privacy considerations Evaluation questions: - Does AI assistance improve code quality or just speed? - Are developers learning or just accepting suggestions? - What happens when AI is unavailable? - How do we review AI-generated code? ## Building Your Mental Model ### The Technology Adoption Curve Technologies at different stages need different evaluation approaches: - Innovation trigger: High risk, high uncertainty, evaluate carefully - Peak of expectations: Hype is highest, scepticism warranted - Trough of disillusionment: Early adopters struggling, realistic assessments emerge - Plateau of productivity: Proven technology, lower risk, realistic expectations ### The Adoption Decision Matrix | Project Characteristics | Technology Risk Tolerance | |------------------------|---------------------------| | Short-lived, experimental | Higher (can pivot easily) | | Long-lived, critical | Lower (need stability) | | Small team, familiar stack | Lower (context switching cost) | | Growing team, scaling | Higher (need better tools) | | Tight deadline | Lower (no time to learn) | | Greenfield project | Higher (no migration cost) | ### Questions That Reveal Reality When evaluating technology, these questions cut through marketing: 1. "What will we stop doing?" - Adoption always has costs 2. "Who has used this for 2+ years?" - Early success doesn't mean long-term success 3. "What's the worst-case migration?" - If it fails, what's the recovery? 4. "Who maintains this?" - Single company? Open community? Foundation? 5. "What problems does the community complain about?" - Reveals real issues ## Business Applications ### Strategic Technology Planning Technology evaluation skills enable business strategy: - Roadmap development: When to adopt which technologies - Risk assessment: Understanding adoption risks - Competitive analysis: What technologies enable competitors - Talent planning: What skills will be needed ### Client Advisory Clients often ask about new technologies. Professional response: Poor: "Yes, blockchain is great, we should use it." Better: "Let me understand your problem first. Blockchain solves specific problems—immutable record-keeping, decentralised consensus. Do you have those problems? If not, simpler solutions exist." ### Career Development Evaluation skills help you: - Prioritise learning: Focus on technologies with staying power - Avoid burnout: Stop chasing every new framework - Build expertise: Go deep on well-chosen technologies - Stay relevant: Recognise genuine shifts versus fads ## ULO Connection This develops ULO 5 (assessing emerging technologies through systematic evaluation). The ability to evaluate technologies objectively—separate from hype and personal preference—is essential for advising businesses on technology decisions. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 12.1: Framework Application (Level 1) Apply the evaluation framework to a technology of your choice: 1. Choose a web technology you've heard about but haven't used 2. Research it using the framework categories (problem fit, maturity, ecosystem, integration, cost) 3. Document your findings for each category 4. Write a one-paragraph recommendation ### Exercise 12.2: Historical Analysis (Level 2) Research a technology that was popular 5 years ago but is less used now: 1. What problem did it solve? 2. Why did adoption decline? 3. What replaced it? 4. What could evaluators have noticed earlier? Write 300 words on lessons learned. ### Exercise 12.3: Comparative Evaluation (Level 3) You need to choose between two competing technologies (e.g., two CSS frameworks, two state management libraries, two build tools): 1. Define your evaluation criteria 2. Research both technologies 3. Score each against your criteria 4. Make a recommendation with clear reasoning 5. Note what would change your recommendation ### Exercise 12.4: Context-Dependent Recommendation (Level 4) A client asks whether they should adopt a specific new technology. Create three different recommendations based on three different client contexts: 1. Early-stage startup with 2 developers, moving fast 2. Established company with 20 developers, maintaining legacy systems 3. Enterprise with strict compliance requirements For each, explain how context changes the recommendation. ### Exercise 12.5: Technology Radar (Level 5) Create your own "Technology Radar" for web development: 1. Research 8-12 current web technologies 2. Categorise each as: Adopt, Trial, Assess, or Hold 3. For each, write 100-150 words justifying the categorisation 4. Note your assumptions and biases 5. Identify what new information would change your categorisations This mirrors how technology advisory firms like ThoughtWorks communicate recommendations. ## Chapter Summary - Evaluation frameworks outlast specific technologies - Technology adoption is an investment decision with costs and risks - Context determines whether a technology is appropriate - The hype cycle helps calibrate expectations - Questions that reveal trade-offs are more valuable than feature lists - Professional technologists advise based on client needs, not personal preferences ## Reflection Before moving to Chapter 13, ensure you can: - [ ] Apply a systematic evaluation framework to any technology - [ ] Identify signs of hype versus genuine value - [ ] Explain how context affects technology recommendations - [ ] Describe the hype cycle and its implications - [ ] Ask questions that reveal technology trade-offs - [ ] Make recommendations appropriate to specific business contexts ## Your Learning Journal Record your responses to these prompts: 1. Personal Bias Awareness: What technologies are you biased toward or against? How might this affect your evaluations? 2. Hype Recognition: Think of a technology you were excited about that didn't deliver. What signs did you miss? 3. AI Conversation Reflection: What technology did you evaluate with AI help? What did you learn about the evaluation process? 4. Future Prediction: What technology do you think will be much more or less important in 5 years? What's your reasoning? ## Next Steps You now have tools to evaluate any technology that emerges. But technology skills alone don't build a career. In , we'll focus on your professional development—building a portfolio, positioning yourself in the market, networking effectively, and planning continuous growth. Technical skill opens doors; professional skill keeps them open. ============================================================ SOURCE: chapters/chapter-development-career.qmd ============================================================ # Your Development Career ## The Concept First In , you learned to evaluate technologies systematically. But technical skills alone don't build careers—they create potential. Converting that potential into opportunities requires a different skill set: professional development. Consider two developers with identical technical abilities: - Developer A: Strong skills, no online presence, applies to jobs cold, waits for opportunities - Developer B: Strong skills, portfolio showcasing work, active in communities, creates opportunities Developer B will have more options, better offers, and a clearer path forward. Not because they're more talented, but because they've made their talent visible and accessible. This chapter isn't about self-promotion or personal branding gimmicks. It's about the practical work of building a professional presence that accurately represents your capabilities and connects you with opportunities that match your goals. ## Understanding Through Career Capital Think of your career as a form of capital accumulation. You build different types of capital: Technical Capital: Your skills and knowledge - The languages you know - The frameworks you've used - The problems you've solved Social Capital: Your professional relationships - People who know your work - Communities you contribute to - References who vouch for you Reputation Capital: How you're perceived - Your portfolio and public work - Contributions others can see - Your professional presence Most developers focus only on technical capital. But technical capital without social and reputation capital means opportunities don't find you—you have to chase every one. ## The Visibility Principle Skills that people can see are worth more than skills they can't. A public project demonstrates capability in ways a resume cannot. Documentation you've written, code you've shared, and problems you've solved publicly all create evidence of competence. ## Discovering Career Building with Your AI Partner ### Exploration 1: Portfolio Strategy Key insights: Quality over quantity: Three excellent projects beat ten mediocre ones Show thinking, not just code: - Why you made certain decisions - Challenges you overcame - What you'd do differently Variety that tells a story: - Different technologies demonstrating range - Increasing complexity showing growth - Business problems solved, not just technical exercises ### Exploration 2: Professional Positioning You can't be excellent at everything. Positioning means being known for something specific. Positioning isn't limiting—it's focusing: - Generalist trap: "I do everything" means "Hire me for anything" which often means "Hire someone else who specialises" - Specialist value: "I build accessible React applications" is memorable and referable - Evolution: Your positioning can change as you grow ### Exploration 3: Networking Without Networking Many developers dislike traditional networking. But professional relationships matter. Developer-friendly relationship building: - Contribute to open source: Work alongside others, earn respect through code - Answer questions: Stack Overflow, Reddit, Discord communities - Write about learning: Blog posts help others and demonstrate expertise - Attend (or speak at) meetups: Even quietly attending builds familiarity ### Exploration 4: Continuous Learning Technology changes. Your learning must continue. Effective continuous learning: - Learn by doing: Projects beat tutorials - Just-in-time learning: Learn what you need for current work - Depth over breadth: Master one thing rather than sampling many - Teach to learn: Explaining forces understanding ## From Concept to Code Let's make this practical. ### Building Your Portfolio Your portfolio demonstrates capability. Structure it intentionally. Portfolio website essentials: Project case study template: Example project description: ```markdown ## Business Dashboard (React + WordPress) Overview: A React single-page application that displays business data from a WordPress backend, demonstrating headless architecture. The Challenge: Create a modern, fast frontend while allowing non-technical staff to manage content through WordPress. My Approach: Chose React for component reusability and WordPress REST API for content management. Used Tailwind for rapid styling. Prioritised loading states and error handling for reliability. Technologies: React, WordPress REST API, Tailwind CSS, Vite Key Features: - Dynamic content fetched from WordPress - Responsive design (mobile-first) - Loading skeletons for perceived performance - Filter and search functionality Challenges Overcome: WordPress featured images required the `_embed` parameter—debugging this taught me to read API documentation more carefully and test endpoints directly. What I Learned: Headless architecture separates concerns effectively. The frontend can evolve independently of the CMS. I'd add TypeScript next time for better maintainability. Links: [Live Demo] [GitHub] [Blog Post: Headless WordPress Lessons] markdown # Hi, I'm [Your Name] I build web applications with a focus on [your positioning]. ## Currently Working On - 🔨 [Current project] - 📚 Learning [current focus] ## Recent Projects - Project 1 - Brief description - Project 2 - Brief description - Project 3 - Brief description ## Technologies ## Get in Touch - Portfolio: [link] - LinkedIn: [link] - Email: [email] Ask your AI: I want to write a blog post about something I learned while building my React project. Help me brainstorm topics that would be useful to other beginners and demonstrate my understanding. Opportunities ▲ │ ┌───────────────┼───────────────┐ │ │ │ │ Technical │ Reputation │ │ Capital │ Capital │ │ (Skills) │ (Visible │ │ │ work) │ │ ▲ │ ▲ │ │ │ │ │ │ │ └───────┼───────┘ │ │ │ │ │ Social Capital │ │ (Relationships) │ │ ▲ │ │ │ │ └───────────────┴───────────────┘ │ Your Effort Build Skills → Create Projects → Share Work → Build Relationships ▲ │ │ │ └───────── Get Opportunities ◄───────────────────┘ Specialist │ ┌───────────┼───────────┐ │ │ │ Frontend │ "React │ "Full- │ Full-Stack │ Dev" │ Stack │ │ │ Dev" │ ├───────────┼───────────┤ │ "WordPress│ "Agency │ │ Dev" │ Dev" │ │ │ │ └───────────┼───────────┘ │ Generalist ``` Different positions have different advantages: - Specialist: Higher rates, clearer referrals, deeper expertise - Generalist: More flexibility, broader opportunities, varied work - Neither is better—choose based on your preferences and market ## Business Applications ### Understanding the Hiring Perspective Employers evaluating candidates consider: - Risk: Will this person succeed or create problems? - Evidence: What demonstrates capability? - Fit: Will they work well with the team? - Growth: Can they improve and adapt? Your portfolio and presence reduce perceived risk by providing evidence. Everything you make public helps employers answer "Can this person do the job?" ### The Value of Visible Contributions Open source contributions, blog posts, and public projects: - Demonstrate skills without requiring trust - Show communication ability (code is communication) - Indicate engagement with the community - Provide conversation starters in interviews Even small contributions count. A typo fix in documentation shows you engage with the ecosystem. ### Long-term Career Planning Think beyond the first job: - Year 1-2: Build foundation, try different areas - Year 3-5: Develop specialisation, build reputation - Year 5+: Leadership opportunities, consulting, teaching Each stage requires different strategies. Early career is about learning and visibility. Later career is about leverage and impact. ## ULO Connection This develops ULO 2 (professional communication and project management). Career development isn't separate from technical work—it's how you translate technical capability into professional opportunity. These skills matter regardless of which technologies you ultimately work with. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 13.1: Portfolio Audit (Level 1) Evaluate your current portfolio presence: 1. Google your name—what comes up? 2. Review your GitHub profile—what does it communicate? 3. Check your LinkedIn—is it complete and current? 4. List three things you could improve immediately ### Exercise 13.2: Project Case Study (Level 2) Write a case study for one of your projects using the template provided: 1. Choose your strongest project 2. Complete all sections of the template 3. Get feedback from a peer 4. Revise based on feedback ### Exercise 13.3: Professional Positioning (Level 3) Develop your professional positioning: 1. List your strongest skills 2. Identify which combinations are distinctive 3. Research job postings that match your skills 4. Write a positioning statement (one sentence that describes what you do) 5. Get feedback—is it clear? Memorable? Accurate? ### Exercise 13.4: Content Creation (Level 4) Create professional content: 1. Write a technical blog post about something you learned 2. Publish it (dev.to, Medium, personal blog, or LinkedIn) 3. Share it on one social platform 4. Reflect: What was harder than expected? What did you learn from writing? ### Exercise 13.5: Career Strategy (Level 5) Develop a 12-month career strategy: 1. Define where you want to be in one year 2. Identify the gaps between current state and goal 3. Create a plan with monthly milestones 4. Include: skills to develop, projects to build, connections to make, content to create 5. Write 500 words explaining your strategy and reasoning ## Chapter Summary - Technical skills create potential; professional presence creates opportunities - Portfolios should show thinking, not just code - Positioning helps you be memorable and referable - Relationships develop through contribution, not just networking - Continuous learning requires intentional practice, not just consumption - Career development is a long game—invest consistently ## Reflection Before moving to Chapter 14, ensure you can: - [ ] Explain what makes a strong portfolio project - [ ] Write a compelling project case study - [ ] Describe your professional positioning - [ ] Identify at least three ways to build professional relationships - [ ] Plan continuous learning without chasing every trend - [ ] Understand what employers look for beyond technical skills ## Your Learning Journal Record your responses to these prompts: 1. Portfolio Assessment: What's the strongest thing in your current portfolio? What's the biggest gap? 2. Positioning Exploration: What do you want to be known for? How does this align with your interests and the market? 3. AI Conversation Reflection: What career question did you explore with AI? What insight was most valuable? 4. Networking Comfort: What forms of professional relationship building feel authentic to you? What would you avoid? ## Next Steps You now have frameworks for building your professional presence and planning your career development. In , we'll conclude by examining what it means to be a developer in the AI era. How do AI tools change the profession? What skills remain essential? How do you prepare for a future where AI capabilities continue to expand? ============================================================ SOURCE: chapters/chapter-ai-era-developer.qmd ============================================================ # The AI-Era Developer ## The Concept First Throughout this book, you've learned web development with AI as your partner. You've used AI to explore concepts, debug problems, generate code, and build understanding. Now, as we conclude, let's step back and ask: What does it mean to be a developer in an era where AI can write code? This isn't a question about job security—though that concern is understandable. It's a deeper question about value, identity, and skill. Consider what you've actually done in this course: - You decided what to build - You evaluated whether solutions were appropriate - You understood why code worked (or didn't) - You communicated with stakeholders (real or imagined) - You judged trade-offs between approaches - You adapted suggestions to your specific context AI assisted with all of this. But AI didn't do any of this for you. The judgment, understanding, and decision-making were yours. That's the core insight: AI amplifies human capability. It doesn't replace human judgment. ## Understanding Through Partnership Evolution Think about how your relationship with AI has evolved through this book. Early in your journey (chapters 1-4): - AI explained concepts - You asked "how does this work?" - AI provided examples - You learned fundamentals As you grew (chapters 5-11): - You asked "which approach is better?" - AI provided options with trade-offs - You made decisions based on context - AI helped implement your decisions Now (chapters 12-14): - You ask "is this appropriate for this situation?" - AI provides analysis - You evaluate and judge - The partnership is truly collaborative This evolution reflects how professionals actually work with AI. Beginners need more guidance. Experts need thinking partners. The AI adapts to where you are. ## The Question Quality Principle As you develop expertise, the quality of questions you ask AI improves. Beginner questions: "How do I centre a div?" Expert questions: "Given these constraints, what are the trade-offs between these three architectural approaches?" Better questions yield better AI partnership. ## Discovering Your AI-Era Role with Your AI Partner ### Exploration 1: What Won't Be Automated Let's think critically about AI's limits: Key areas that remain human: Problem definition: AI can solve problems; it struggles to identify which problems matter. "We need better user engagement" is a human judgment. AI can't determine what "better" means for your specific business. Stakeholder communication: Clients often don't know what they want. Extracting requirements through conversation, reading non-verbal cues, and building trust remain human skills. Ethical judgment: "Can we build this?" differs from "Should we build this?" AI can identify potential issues but can't make values-based decisions for you. Context switching: Developers constantly shift between technical depth, business strategy, user empathy, and team dynamics. This fluid context-awareness is distinctly human. Accountability: When something goes wrong, humans are accountable. This responsibility shapes how we approach work in ways AI doesn't replicate. ### Exploration 2: Your Unique Value Honest assessment of human value: - Caring about outcomes: AI doesn't care if your project succeeds. You do. - Understanding consequences: You understand that slow-loading pages frustrate real humans. - Navigating ambiguity: Real requirements are messy. "Make it better" requires human interpretation. - Building relationships: Clients hire people, not AI. Trust is human. - Learning from failure: You remember what didn't work and why. This wisdom guides future decisions. ### Exploration 3: Effective AI Partnership Effective AI partnership practices: Verify, don't trust blindly: AI makes confident-sounding errors. Always test generated code. Understand what AI gives you: Don't use code you can't explain. If AI generates something, understand it before committing. Iterate conversationally: One-shot prompts rarely produce optimal results. Refine through dialogue. Provide context: AI works better with more context. Share constraints, goals, and existing code. Stay critical: Just because AI suggests something doesn't make it right. Evaluate every suggestion. ### Exploration 4: The Future Partnership Possible evolutions: - More capable code generation: AI will write more complex code more reliably - Better context awareness: AI will understand your codebase more deeply - Integration with development workflows: AI embedded in all tools - New specialisations: AI trainers, prompt engineers, AI-human coordinators What remains constant: - Need for human judgment about what to build - Requirement to understand what code does - Importance of stakeholder communication - Responsibility for outcomes ## From Concept to Practice ### Patterns for AI Collaboration Throughout this course, you've developed patterns for working with AI. Let's make them explicit. Pattern 1: Exploration Before Implementation Explore options before committing. AI is excellent at laying out alternatives. Pattern 2: Explain, Then Generate Understanding before fixing leads to better solutions and learning. Pattern 3: Incremental Building Complex systems are built incrementally. AI helps with each step, not magic solutions. Pattern 4: Context-Rich Requests ``` Poor: "Make the button look better" Better: "This button is the primary call-to-action for signup. It's in a hero section with a dark background image. Currently it's styled with Tailwind as `bg-blue-500 text-white px-4 py-2`. The button feels too small and doesn't stand out enough. Suggest improvements that maintain accessibility." Full Manual Full Automation │ │ ├────────┬────────┬────────┬────────┬────────────┤ │ │ │ │ │ │ Writing Research Code Code Complete from + ideation assist review generation scratch ▲ │ Current AI assistance (effective) Traditional Developer AI-Era Developer ───────────────────── ───────────────────── Writing code Directing code creation Memorising syntax Understanding concepts Solo problem-solving Collaborative reasoning Deep specialisation Broad orchestration + selective depth ▼ Skills that GAIN value: • Problem definition • Communication • Judgment and evaluation • Learning ability • Ethical reasoning Skills that CHANGE form: • Coding → directing + reviewing • Research → prompting + verifying • Debugging → explaining + guiding Level 1: User - AI does tasks for you - You accept outputs uncritically - Dependency without understanding Level 2: Consumer - AI assists your work - You evaluate outputs - Selective use Level 3: Collaborator - AI thinks with you - You guide direction - True partnership Level 4: Director - AI amplifies your judgment - You orchestrate capabilities - AI is your tool, not your crutch ``` Progress through these levels by maintaining your independent capability while leveraging AI appropriately. ## Business Applications ### Productivity and Quality AI-assisted development can improve both speed and quality—if used well: - Speed: Faster prototyping, less boilerplate - Quality: More time for design and review - Learning: Faster skill acquisition - Exploration: Try more approaches The key: time saved on rote tasks should be invested in higher-value activities (design, testing, user research), not just producing more code faster. ### Team Dynamics AI changes how teams work: - Review processes: Now include AI-generated code review - Skill distribution: AI democratises some capabilities - Communication: More emphasis on clear requirements - Training: Onboarding includes AI tool proficiency ### Client Communication Explaining AI involvement to clients: Honest framing: "We use AI tools to enhance our productivity. All AI-generated code is reviewed and tested by our developers. The AI assists; humans remain responsible for quality." Value focus: "AI helps us explore more options and iterate faster. This means you get better solutions, not just faster delivery." ### Career Positioning In an AI-augmented field: - Differentiate on judgment: Anyone can generate code; not everyone can evaluate it - Emphasise communication: Translating between humans and systems gains value - Build domain expertise: AI is generic; domain knowledge is specific - Demonstrate responsibility: Show you can be trusted with AI tools ## ULO Connection This develops all five ULOs—particularly ULO 1 (evaluating and improving solutions) and ULO 5 (assessing emerging technologies). Working effectively with AI is now a core professional skill, requiring the judgment, communication, and evaluation abilities developed throughout this course. ## Practice Exercises ## Exercise Levels - Level 1: Direct application - Level 2: Minor modifications - Level 3: Combining concepts - Level 4: Problem-solving - Level 5: Open-ended design ### Exercise 14.1: AI Interaction Analysis (Level 1) Review your AI conversations from throughout this course: 1. Find three conversations where AI was most helpful 2. Find one conversation where AI led you astray 3. For each, identify what made the interaction effective or ineffective 4. Write patterns you'll use going forward ### Exercise 14.2: Manual Implementation (Level 2) Build a small component without AI assistance: 1. Choose something you previously built with AI help 2. Implement it from scratch using only documentation 3. Compare: What was harder? What did you understand better? 4. Reflect on the value of both approaches ### Exercise 14.3: AI Code Review (Level 3) Practice reviewing AI-generated code: 1. Ask AI to generate a moderately complex component 2. Review it using the checklist provided 3. Identify at least three improvements 4. Discuss the improvements with AI 5. Implement the final version ### Exercise 14.4: Partnership Optimisation (Level 4) Develop your personal AI collaboration framework: 1. Document your most effective prompting patterns 2. Create a personal checklist for AI-generated code 3. Define boundaries (when you will/won't use AI) 4. Write guidelines for a team member new to AI tools ### Exercise 14.5: Future Preparation (Level 5) Create a 12-month professional development plan that accounts for AI: 1. Identify skills that will gain value with AI assistance 2. Identify skills you need to maintain independently 3. Plan specific learning activities for each 4. Define how you'll measure your progress 5. Write 500 words explaining your strategy ## Chapter Summary - AI amplifies human capability; it doesn't replace human judgment - Effective AI partnership requires understanding, evaluation, and adaptation - Maintaining independent skills prevents over-reliance - The value shifts to problem definition, communication, and judgment - Ethical use requires honesty, quality responsibility, and integrity - Career success depends on how well you collaborate with AI, not whether ## Final Reflection As you complete this book, reflect on your journey: Technical Growth: - [ ] Can you build web applications with HTML, CSS, and JavaScript? - [ ] Can you work with WordPress as both a CMS and an API? - [ ] Can you create React components and manage state? - [ ] Can you evaluate and adopt CSS frameworks appropriately? Professional Development: - [ ] Can you make and defend technology decisions? - [ ] Can you communicate technical concepts to non-technical stakeholders? - [ ] Can you use version control and professional practices? - [ ] Can you evaluate emerging technologies systematically? AI Partnership: - [ ] Can you collaborate effectively with AI tools? - [ ] Do you maintain your own understanding and skills? - [ ] Can you evaluate AI output critically? - [ ] Are you positioned to adapt as AI capabilities evolve? ## Your Final Learning Journal Entry Record your thoughts on completing this course: 1. Your Journey: What surprised you most about learning web development? What was harder than expected? Easier? 2. AI Partnership Evolution: How did your relationship with AI tools change from the beginning to now? What patterns work best for you? 3. Business Thinking: How do you now approach technology decisions differently than when you started? 4. Identity: How do you see yourself as a developer? What kind of professional do you want to become? 5. Next Steps: What will you build next? What will you learn? How will you continue growing? ## Looking Forward This book ends, but your development journey continues. You now have: - Technical foundations across the modern web stack - Business thinking for technology decisions - AI collaboration skills for enhanced productivity - Professional practices for quality work - Career frameworks for ongoing growth More importantly, you have the ability to learn. Technologies will change. Frameworks will evolve. AI capabilities will expand. But your foundation—understanding how to think about problems, evaluate solutions, communicate with stakeholders, and collaborate with tools—remains valuable. The developers who thrive in the AI era won't be those who resist AI or those who depend on AI. They'll be those who partner with AI thoughtfully—maintaining their own judgment, understanding, and skills while leveraging AI to amplify their capability. You've built that foundation here. Now go build something. Make mistakes. Learn from them. Collaborate with AI. Create value for others. Contribute to the community. Keep growing. Welcome to your career as a web professional. ============================================================ SOURCE: references.qmd ============================================================ # References ============================================================ SOURCE: about-author.qmd ============================================================ # About the Author Michael Borck is a software developer and educator passionate about the intersection of human expertise and artificial intelligence. He developed the Intentional Prompting methodology to help programmers maintain agency and deepen their understanding while leveraging AI tools effectively. Michael believes that the future of programming lies not in delegating to AI, but in conversing with it---treating AI as a collaborative partner that enhances human capability rather than replacing human understanding. When not writing about AI collaboration, Michael works on practical applications of these principles across software development, education, and creative projects. He creates educational software and resources, and explores the 80/20 principle in learning and productivity. --- Connect - michaelborck.dev --- Professional work and projects - michaelborck.education --- Educational software and resources - 8020workshop.com --- Passion projects and workshops - LinkedIn --- Other Books in This Series Foundational Methodology: - Conversation, Not Delegation: Your Expertise + AI's Breadth = Amplified Thinking - Converse Python, Partner AI: The Python Edition Python Track: - Think Python, Direct AI: Computational Thinking for Beginners - Code Python, Consult AI: Python Fundamentals for the AI Era - Ship Python, Orchestrate AI: Professional Python in the AI Era For Educators: - Partner, Don't Police: AI in the Business Classroom