A to Z — Professional Practice: Batch 6
Only A to Z Practice Lessons · Existing home design and other modules unchanged
Three full guided workflows · 36 theory/practical checkpoints
Lesson Index
These are detailed guided checklists, not a substitute for testing against your installed tool versions. No claim of a working production deployment.
Firebase Authentication — Secure Login Project
Outcome: Create an email/password authentication flow for a demo Flutter app, including rules, error handling, and tests.
Prerequisites: Use a demo project, a modern browser and the relevant development/design tools. Do not publish credentials, real user data, or copyrighted assets.
Point 01 — Define user journeys
Theory: Authentication proves identity; authorization decides permitted data access.
Why and how: Sketch sign up, verify email, sign in, reset password, sign out, and account deletion as distinct flows.
Expected output: Six flows documented.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 02 — Create a Firebase project
Theory: A Firebase project groups app configurations and cloud resources.
Why and how: Open Firebase Console, create a test project, record its project ID and billing configuration; never paste credentials into a public repo.
Expected output: Test project appears in console.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 03 — Register Android app
Theory: Android package name identifies the application to Firebase.
Why and how: In Project settings add Android app with exact applicationId from app/build.gradle; download google-services.json into app/.
Expected output: Firebase Android app registered.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 04 — Understand SHA fingerprints
Theory: SHA-1/SHA-256 identify signing certificates; some sign-in providers require them.
Why and how: For email/password alone SHA fingerprints are generally not required. For Google sign-in obtain debug/release SHA from Gradle signingReport and register correct values.
Expected output: Provider-specific SHA requirements understood.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 05 — Connect FlutterFire
Theory: FlutterFire CLI generates platform-specific options; secrets must still be protected by server rules.
Why and how: Install Flutter/Dart and Firebase CLI; run dart pub global activate flutterfire_cli then flutterfire configure inside Flutter project.
Expected output: lib/firebase_options.dart generated.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 06 — Initialize SDK
Theory: Firebase.initializeApp establishes app connection before Auth calls.
Why and how: Add firebase_core and firebase_auth; initialize in main() using DefaultFirebaseOptions.currentPlatform before runApp.
Expected output: App launches without initialization error.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 07 — Enable sign-in provider
Theory: Firebase Auth providers must be enabled explicitly.
Why and how: In Authentication → Sign-in method enable Email/Password. Keep test users fictional.
Expected output: Email/password provider enabled.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 08 — Build registration form
Theory: Validate client inputs for usability; backend Auth still enforces account rules.
Why and how: Add email, password, confirm-password fields; check empty values, password length, and matching confirmation before submission.
Expected output: Invalid entries show inline feedback.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 09 — Create account
Theory: createUserWithEmailAndPassword returns a credential or throws FirebaseAuthException.
Why and how: Call createUserWithEmailAndPassword; catch weak-password, email-already-in-use, invalid-email and network errors; never log passwords.
Expected output: Demo user created or meaningful error shown.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 10 — Verify email and login
Theory: Email verification reduces abuse; sessions persist securely through SDK state.
Why and how: Call sendEmailVerification; on return refresh user and check emailVerified; sign in via signInWithEmailAndPassword.
Expected output: Verified user reaches protected screen.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 11 — Protect Firestore data
Theory: UI hiding is not access control; Firestore Security Rules are enforced server-side.
Why and how: Use rules matching users/{uid} with request.auth != null && request.auth.uid == uid; deny other documents by default; test in emulator.
Expected output: User A cannot read User B profile.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 12 — Reset, sign out, and test
Theory: Lifecycle flows and negative tests matter as much as happy path.
Why and how: Implement sendPasswordResetEmail, signOut, authStateChanges; test wrong password, offline mode, disabled account, other-user reads, and re-login.
Expected output: Recorded pass/fail checklist for all flows.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Final assignment
Complete all twelve points, save your project source and screenshots, write a 200-word explanation of decisions, and record at least three errors you tested and resolved.
Self-assessment
- What is the main purpose of this workflow?
- Which settings or artifacts must be verified before release?
- How would you reproduce and fix a failed test?
Video / Audio: Production outline only. No pre-recorded voice or video is included. PDF: Print this lesson using your browser’s Save as PDF.
SEO — Publish and Audit a Realistic Service Page
Outcome: Optimize a fictional local service landing page without making ranking guarantees.
Prerequisites: Use a demo project, a modern browser and the relevant development/design tools. Do not publish credentials, real user data, or copyrighted assets.
Point 01 — Choose audience and intent
Theory: Search intent describes the problem behind a query.
Why and how: Write audience, service, location if relevant, and one primary question the page answers.
Expected output: One-sentence intent statement.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 02 — Research query themes
Theory: Keyword research groups related questions; volume estimates are not guarantees.
Why and how: Create a sheet with primary phrase, five supporting phrases, search intent, and target section.
Expected output: Keyword-to-section map.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 03 — Review search results responsibly
Theory: Existing results reveal page formats and user expectations.
Why and how: Inspect relevant public results manually; note common questions and gaps without copying content.
Expected output: Original content brief.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 04 — Plan headings
Theory: A clear H1 and logical H2/H3 hierarchy help navigation.
Why and how: Write one descriptive H1 and 3–5 H2 headings that answer user questions.
Expected output: Semantic outline.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 05 — Write useful original content
Theory: Helpful information must match the page purpose, not repeat keywords.
Why and how: Draft 500–900 original words with service process, pricing caveats, examples, and a clear next action.
Expected output: Readable draft with specific details.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 06 — Create metadata
Theory: Title and description are suggestions to search engines, not guaranteed snippets.
Why and how: Write a unique title around 50–60 characters and a useful description; avoid keyword stuffing.
Expected output: Distinct title and meta description.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 07 — Add semantic HTML
Theory: Semantic tags improve structure and accessibility.
Why and how: Use header, nav, main, section, footer; label form inputs and add meaningful link text.
Expected output: Valid semantic page structure.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 08 — Optimize images
Theory: Descriptive alt text aids accessibility; compression reduces transfer cost.
Why and how: Export appropriately sized WebP/AVIF where supported, set width/height and relevant alt text; omit decorative alt content.
Expected output: Faster, accessible image rendering.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 09 — Check mobile usability
Theory: Mobile-first indexing makes mobile content and usability important.
Why and how: Test at 360px and 768px, tap targets, text overflow, form fields, and navigation.
Expected output: No horizontal scrolling or hidden actions.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 10 — Add structured data carefully
Theory: Structured data must accurately represent visible content and supported types.
Why and how: If appropriate add valid JSON-LD describing the organization; avoid fake ratings or unsupported claims.
Expected output: Schema validates without misleading fields.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 11 — Set canonical and sitemap
Theory: Canonical helps signal preferred URL; sitemap supports discovery.
Why and how: Use absolute canonical URL, robots.txt and sitemap.xml with real published URLs only.
Expected output: Canonical and sitemap match live site.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 12 — Measure and iterate
Theory: Search Console tracks indexing and queries; ranking changes take time.
Why and how: Verify ownership, submit sitemap, inspect URL, monitor impressions/CTR and Core Web Vitals, log revisions monthly.
Expected output: Documented SEO improvement cycle.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Final assignment
Complete all twelve points, save your project source and screenshots, write a 200-word explanation of decisions, and record at least three errors you tested and resolved.
Self-assessment
- What is the main purpose of this workflow?
- Which settings or artifacts must be verified before release?
- How would you reproduce and fix a failed test?
Video / Audio: Production outline only. No pre-recorded voice or video is included. PDF: Print this lesson using your browser’s Save as PDF.
Creator Studio — Professional Thumbnail Workflow
Outcome: Create an original, readable 1280×720 thumbnail with reusable brand components.
Prerequisites: Use a demo project, a modern browser and the relevant development/design tools. Do not publish credentials, real user data, or copyrighted assets.
Point 01 — Define the promise
Theory: A thumbnail should communicate the actual video topic without deceptive claims.
Why and how: Write the video promise in one sentence and choose a truthful visual hook.
Expected output: One clear concept.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 02 — Set canvas
Theory: YouTube thumbnail design commonly uses 16:9 composition.
Why and how: Create a 1280×720 canvas in your design tool; set safe internal margins.
Expected output: Correct aspect ratio.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 03 — Choose hierarchy
Theory: Visual hierarchy directs attention to subject, headline, and brand.
Why and how: Place one primary focal subject, one short headline, and a small brand mark.
Expected output: Three-level hierarchy.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 04 — Plan brand system
Theory: Consistent color and type choices build recognition.
Why and how: Pick two brand colors, one accent, and two readable font weights; document HEX values.
Expected output: Reusable brand tokens.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 05 — Use legitimate images
Theory: Only use media you own or have rights to use.
Why and how: Import original photos or licensed assets; retain license records where relevant.
Expected output: Source list recorded.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 06 — Remove background cleanly
Theory: Subject separation can improve clarity but needs edge quality checks.
Why and how: Mask subject manually or with an editor; inspect hair, hands, and shadows at 100%.
Expected output: Clean cutout.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 07 — Write short headline
Theory: Few large words usually work better than dense text on phones.
Why and how: Create a 3–5 word truthful title; test at thumbnail size.
Expected output: Headline legible at small scale.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 08 — Control contrast
Theory: Foreground/background contrast determines readability.
Why and how: Apply solid text backing or subtle shadow; check light and dark regions.
Expected output: Headline remains readable.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 09 — Compose for mobile
Theory: Most viewers see a reduced image before clicking.
Why and how: Shrink preview to ~160px wide; reposition elements that become unreadable.
Expected output: Mobile-ready composition.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 10 — Export versions
Theory: Format and compression affect image quality and file size.
Why and how: Export PNG or JPEG and inspect final 1280×720 dimensions and platform size limits.
Expected output: Upload-ready file.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 11 — Create A/B variants
Theory: Variants test a hypothesis rather than changing everything randomly.
Why and how: Make version B with only one major difference, such as headline or focal subject.
Expected output: Two comparable variants.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Point 12 — Review and deliver
Theory: Final QA catches typos, rights issues, and brand inconsistency.
Why and how: Check spelling, contrast, crop, copyright, naming, editable source, and final preview; archive master file.
Expected output: Complete client-ready thumbnail package.
Practice check: Complete this step in your own demo project and capture a screenshot or short note showing the expected output.
Final assignment
Complete all twelve points, save your project source and screenshots, write a 200-word explanation of decisions, and record at least three errors you tested and resolved.
Self-assessment
- What is the main purpose of this workflow?
- Which settings or artifacts must be verified before release?
- How would you reproduce and fix a failed test?
Video / Audio: Production outline only. No pre-recorded voice or video is included. PDF: Print this lesson using your browser’s Save as PDF.